From jeff.pitman at gmail.com Sun Jan 1 05:57:32 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Sun, 1 Jan 2006 13:57:32 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <20051231233759.GD1197025@hiwaay.net> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> Message-ID: <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> On 1/1/06, Chris Adams wrote: > Once upon a time, John Ellson said: > > However, I doubt that overlaps can be completely eliminated, or that > > it is even desirable to completely eliminate them, so I think it is > > more important to have a clear mechanism to allow the user to control > > the default choice, and to be able to override it if desired. > > The best thing would be for the third-party repos to be split into > overlapping and non-overlapping. Anything that doesn't replace a Core > or Extras package (or require such a package) could go in a > non-overlapping repo and things that does could go in an "alternatives" > repo. It could be doable. But, it would be inconsistent in some cases and also would be a major set back as things would have to be restructured. For example, the reason there are so many overlapping packages between RPMforge and Extras is that the goals have diverged. RPMforge maintains specs in a way that will make them compatible with a wide range of distros. Extras is more of a laser-beam, forward-looking approach. There are groups of people who fall under the banners of either side. The fact of the matter is, is that the user *chose* to integrate the third party repo into their system. The act of doing this should come with responsibility. Protecting them will do nothing to help the situation. -- -jeff From jeff.pitman at gmail.com Sun Jan 1 06:02:11 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Sun, 1 Jan 2006 14:02:11 +0800 Subject: FC5 and Yum Plugins In-Reply-To: <20051231184130.GB15058@neu.nirvana> References: <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <43B6B9ED.7050701@redhat.com> <20051231184130.GB15058@neu.nirvana> Message-ID: <6b9c17630512312202v31326779l4ff0acfc71f6aeef@mail.gmail.com> On 1/1/06, Axel Thimm wrote: > On the contrary I would even assert, that for ATrpms the contrary is > true: packages being replaced have a higher maturity, as they have > either been taken out of ATrpms into FC, or ATrpms has enhanced the > build with more BuildRequires/configure options. Packages required at > a newer version are usually checked against Rawhide. Like a fixed readline lib that didn't core dump when pressing backspace at the beginning of the line. :P I think it took the legacy project over a year to do anything about that. But, I digress. (and I've moved on past RH9 ever since...) -- -jeff From buildsys at redhat.com Sun Jan 1 08:11:49 2006 From: buildsys at redhat.com (Build System) Date: Sun, 1 Jan 2006 03:11:49 -0500 Subject: rawhide report: 20060101 changes Message-ID: <200601010811.k018BnDI032752@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.14-1.1806_FC5 ------------------------ * Sat Dec 31 2005 Dave Jones - 2.6.15-rc7-git5 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5smp jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) From mpeters at mac.com Sun Jan 1 08:41:12 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 01 Jan 2006 00:41:12 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <20051231183147.GA15058@neu.nirvana> References: <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> <3adc77210512310757p3115c13buf10b3a6198c95c8b@mail.gmail.com> <604aa7910512310849t4217a176ne884326b12ec0d15@mail.gmail.com> <1136049422.3516.166.camel@pmac.infradead.org> <20051231183147.GA15058@neu.nirvana> Message-ID: <1136104872.11175.9.camel@locolhost.localdomain> On Sat, 2005-12-31 at 19:31 +0100, Axel Thimm wrote: > On Sat, Dec 31, 2005 at 05:17:02PM +0000, David Woodhouse wrote: > > On Sat, 2005-12-31 at 11:49 -0500, Jeff Spaleta wrote: > > Er, or just volunteer to package mythtv for livna? > > That is the second time this suggestion comes up in this thread. What > makes livna and ATrpms different, or say livna preferable to ATrpms in > this context? At the beginning of this thread some people posted about > livna replacing packages just as well. > > Just for the note: Fedora itself, when it wasn't merged with RHL (aka > fedora.us) decided to have vendor packages replaced. packages like > shadow-utils or rpm itself. To be honest - I don't think in general that livna should replace extras packages. It seems that in the cases where it does, it is the same maintainer. I didn't use Fedora before it became Fedora Core - replacing a vendor package is sometimes necessary but should be done with extreme caution. -=- I think protect base plugin is wrong. I like the way smart handled it when I ran it - I could give highest priority to updates, a slightly lower priority to core/extras/livna, and a lower priority to freshrpm's - but give the individual packages I wanted from freshrpms the highest possible priority. If there's a yum plugin that allows that, then it is worth using - but the potential problems outlined by you and and by Jeff Spaleta have convinced me that the protect base plugin should not be enabled because of the core/extras package movement would require protecting both, which is not good because Extras isn't core, and alternative to Extras repositories should be fine for people who (for whatever reason) decide they don't want to use Extras at all. That freedom shouldn't be made more difficult. Maybe yum could use a database of its own for keeping track of what package comes from what? That's probably not a good solution. How does smart do it? From fedora at leemhuis.info Sun Jan 1 12:24:47 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Jan 2006 13:24:47 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <1136104872.11175.9.camel@locolhost.localdomain> References: <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> <3adc77210512310757p3115c13buf10b3a6198c95c8b@mail.gmail.com> <604aa7910512310849t4217a176ne884326b12ec0d15@mail.gmail.com> <1136049422.3516.166.camel@pmac.infradead.org> <20051231183147.GA15058@neu.nirvana> <1136104872.11175.9.camel@locolhost.localdomain> Message-ID: <1136118287.2669.5.camel@localhost.localdomain> Am Sonntag, den 01.01.2006, 00:41 -0800 schrieb Michael A. Peters: > On Sat, 2005-12-31 at 19:31 +0100, Axel Thimm wrote: > > On Sat, Dec 31, 2005 at 05:17:02PM +0000, David Woodhouse wrote: > > > On Sat, 2005-12-31 at 11:49 -0500, Jeff Spaleta wrote: > > > Er, or just volunteer to package mythtv for livna? > > > > That is the second time this suggestion comes up in this thread. What > > makes livna and ATrpms different, or say livna preferable to ATrpms in > > this context? At the beginning of this thread some people posted about > > livna replacing packages just as well. > > > > Just for the note: Fedora itself, when it wasn't merged with RHL (aka > > fedora.us) decided to have vendor packages replaced. packages like > > shadow-utils or rpm itself. I can't remember exactly, but wasn't that in a separate sub-repo and/or for a distribution that was not maintained anymore by Red Hat? > To be honest - I don't think in general that livna should replace extras > packages. I agree -- IMHO audacity in livna should be renamed to audacity-mp3 (or something else, no better idea atm) and conflict with audacity from extras. That way people can uninstall audacity from extras and manually install the version from livna if they want to (maybe it also works with some obsolete-magic, but I don't think so and did not try). Michael, could you file a bug in livna's bugzilla? tia -- Thorsten Leemhuis From fedora at leemhuis.info Sun Jan 1 12:47:12 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Jan 2006 13:47:12 +0100 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <20051231233759.GD1197025@hiwaay.net> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> Message-ID: <1136119632.2669.23.camel@localhost.localdomain> Am Samstag, den 31.12.2005, 17:37 -0600 schrieb Chris Adams: > Once upon a time, John Ellson said: > > However, I doubt that overlaps can be completely eliminated, or that > > it is even desirable to completely eliminate them, so I think it is > > more important to have a clear mechanism to allow the user to control > > the default choice, and to be able to override it if desired. > > The best thing would be for the third-party repos to be split into > overlapping and non-overlapping. And then merge the non-overlapping stuff in one 3rd party community repo where the repo-maintainers work together instead of against each other. Okay, RPMforge might have other goals (see the mail from Jeff Pitman in this thread) so this probably won't fit (but I still wish RPMforge all the best with their approach). But if livna, atrpms and freshrpms all mostly use the "don't replace packages from Core or Extras" approach it might be a good time do forget about old flamewars ^w discussions an try to work together from now on. Disclaimer for those who don't know: I maintain several packages in Livna. /me wonders if he should abort writing this message. /me clicks "Send-Button" and hides -- Thorsten Leemhuis From florin at andrei.myip.org Sun Jan 1 20:59:00 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Sun, 01 Jan 2006 12:59:00 -0800 Subject: edit root alias when installing the OS Message-ID: <1136149140.3230.5.camel@rivendell.home.local> Wouldn't make sense to edit /etc/aliases while installing the OS and ask the operator to provide a real email as an alias? It is a very common error to forget the root alias. As a result, the email sent by housekeeping software (such as logwatch) is ignored, often with unpleasant results. https://www.redhat.com/archives/fedora-list/2006-January/thread.html#00045 This may or may not require to edit the relayhost variable in the MTA (ask the operator to provide a default mail relay), I'm not sure (depending on how "correct" or thorough the installer should be). Anyway, food for thought and discussion. -- Florin Andrei http://florin.myip.org/ From admin at ramshacklestudios.com Sun Jan 1 21:14:18 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Sun, 01 Jan 2006 13:14:18 -0800 Subject: edit root alias when installing the OS In-Reply-To: <1136149140.3230.5.camel@rivendell.home.local> References: <1136149140.3230.5.camel@rivendell.home.local> Message-ID: <1136150058.3376.13.camel@tuxhugger> On Sun, 2006-01-01 at 12:59 -0800, Florin Andrei wrote: > Wouldn't make sense to edit /etc/aliases while installing the OS and ask > the operator to provide a real email as an alias? > It is a very common error to forget the root alias. As a result, the > email sent by housekeeping software (such as logwatch) is ignored, often > with unpleasant results. > > https://www.redhat.com/archives/fedora-list/2006-January/thread.html#00045 > > This may or may not require to edit the relayhost variable in the MTA > (ask the operator to provide a default mail relay), I'm not sure > (depending on how "correct" or thorough the installer should be). That sounds like a good idea to me. Perhaps it could default to aliasing root to the user created during firstboot, or something similar? -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 -------------- 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 pemboa at gmail.com Sun Jan 1 22:23:16 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 1 Jan 2006 16:23:16 -0600 Subject: edit root alias when installing the OS In-Reply-To: <1136149140.3230.5.camel@rivendell.home.local> References: <1136149140.3230.5.camel@rivendell.home.local> Message-ID: <16de708d0601011423o73dea50fh23ea3edc639646a5@mail.gmail.com> On 1/1/06, Florin Andrei wrote: > > Wouldn't make sense to edit /etc/aliases while installing the OS and ask > the operator to provide a real email as an alias? > It is a very common error to forget the root alias. As a result, the > email sent by housekeeping software (such as logwatch) is ignored, often > with unpleasant results. > > https://www.redhat.com/archives/fedora-list/2006-January/thread.html#00045 > > This may or may not require to edit the relayhost variable in the MTA > (ask the operator to provide a default mail relay), I'm not sure > (depending on how "correct" or thorough the installer should be). > > Anyway, food for thought and discussion. > > I think that is a very good idea. I must admit forgetting this myself. Culd this be put in to Anaconda, or at the least could the First Run app use the emnail given for the defailt (uid=500) user? -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpeters at mac.com Sun Jan 1 22:33:12 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 01 Jan 2006 14:33:12 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <20051231195043.GF15058@neu.nirvana> References: <20051231195043.GF15058@neu.nirvana> Message-ID: <1136154793.11175.34.camel@locolhost.localdomain> On Sat, 2005-12-31 at 20:50 +0100, Axel Thimm wrote: > So, is there interest to have ATrpms for FC5 less overlapping with > core packages? > > If so, is there any redhat.com folk that would be willing to add > versioned obsoletes/provides to core specfiles? That's neccessary to > ensure upgradability. This might not be directly on topic to what was asked. Is there a list for repository maintainers? I'm not asking because I think this is on wrong list, but I do think a list to collaboration between repository maintainers, and there is need to replace core packages in some circumstances. IE - if I wrote a program that interfaces with an AM/FM radio tuner card to make mp3's that can be transfered to an iPod. I would probably just use sox to record the stream and output to mp3 - so my software would require an mp3 enabled sox. With proper collaboration - packagers could requires sox-mp3 and the third parties could add Provides: sox-mp3 to their sox spec file. That would allow dep resolvers to know that core sox isn't good enough. I think the fundamental problem here is that EVR is being used to do some of that now, make the third party packages look newer to yum/apt so that dependencies are met - but the side affect that has is that sometimes replacement core packages that AREN'T needed for what the user is doing are pulled into a yum upgrade. A "prefer base" plugin could (perhaps) be written such that core sox will not replaced by a non core package unless it sox is removed from core OR a third party sox provides something needed by another package that core sox does not provide (in this case sox-mp3) I think that would avoid the need for a ton of sub repos to avoid un-necessary core package replacement as it currently is. Even without a yum plugin that does things properly, though - using virtual provides and requires when necessary would at least inform users who have protectbase or whatever turned on that they can't do so and use some third party packages because dependencies would not be met - not based on EVR but based on what the core package doesn't provide that the third party requires. These would need to be agreed upon by the repository maintainers, and a list for that would be beneficial if it doesn't exist. From jarod at wilsonet.com Sun Jan 1 22:51:36 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Sun, 1 Jan 2006 14:51:36 -0800 Subject: edit root alias when installing the OS In-Reply-To: <16de708d0601011423o73dea50fh23ea3edc639646a5@mail.gmail.com> References: <1136149140.3230.5.camel@rivendell.home.local> <16de708d0601011423o73dea50fh23ea3edc639646a5@mail.gmail.com> Message-ID: <200601011451.42702.jarod@wilsonet.com> On Sunday 01 January 2006 14:23, Arthur Pemberton wrote: > On 1/1/06, Florin Andrei wrote: > > Wouldn't make sense to edit /etc/aliases while installing the OS and ask > > the operator to provide a real email as an alias? > > It is a very common error to forget the root alias. As a result, the > > email sent by housekeeping software (such as logwatch) is ignored, often > > with unpleasant results. > > > > https://www.redhat.com/archives/fedora-list/2006-January/thread.html#0004 > >5 > > > > This may or may not require to edit the relayhost variable in the MTA > > (ask the operator to provide a default mail relay), I'm not sure > > (depending on how "correct" or thorough the installer should be). > > > > Anyway, food for thought and discussion. > > > > I think that is a very good idea. I must admit forgetting this myself. > > Culd this be put in to Anaconda, or at the least could the First Run app > use the emnail given for the defailt (uid=500) user? Would probably have to be in firstrun, since there's no user accounts created within Anaconda anymore. A simple check box for "deliver system mail to this user" in firstboot that triggers the change ought to do the trick. That's pretty much what SUSE has been doing for a while now. At firstboot, there shouldn't be any question what MTA is running, unless you've installed via kickstart and explicitly dumped sendmail in favor of another MTA. Now that could get slightly more tricky. I know postfix is set up to use the same aliases file, but they have to be postmapped, and I don't know about exim (or even recall if that's an install-time option anymore). Certainly still doable though. -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jarod at wilsonet.com Sun Jan 1 22:53:41 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Sun, 1 Jan 2006 14:53:41 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136154793.11175.34.camel@locolhost.localdomain> References: <20051231195043.GF15058@neu.nirvana> <1136154793.11175.34.camel@locolhost.localdomain> Message-ID: <200601011453.41983.jarod@wilsonet.com> On Sunday 01 January 2006 14:33, Michael A. Peters wrote: > Is there a list for repository maintainers? http://lists.atrpms.net/mailman/listinfo/repo-coord -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mpeters at mac.com Sun Jan 1 23:05:07 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 01 Jan 2006 15:05:07 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <20051231233759.GD1197025@hiwaay.net> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> Message-ID: <1136156708.11175.37.camel@locolhost.localdomain> On Sat, 2005-12-31 at 17:37 -0600, Chris Adams wrote: > Once upon a time, John Ellson said: > > However, I doubt that overlaps can be completely eliminated, or that > > it is even desirable to completely eliminate them, so I think it is > > more important to have a clear mechanism to allow the user to control > > the default choice, and to be able to override it if desired. > > The best thing would be for the third-party repos to be split into > overlapping and non-overlapping. The problem is there are a fair number of packages that are not overlapping but depend upon overlapping. So it really is difficult if you have a sizeable repository like Axel does. AFAIK he's also supporting a large number of Fedora releases, and he's not charging anybody any money for it either. I think there could be a better solution that would allow him to spend more time on packages and less on repo monkey work. From sundaram at redhat.com Sun Jan 1 23:54:54 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 02 Jan 2006 05:24:54 +0530 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> Message-ID: <43B86BCE.6020302@redhat.com> Hi >The fact of the matter is, is that the user *chose* to integrate the >third party repo into their system. The act of doing this should come >with responsibility. Protecting them will do nothing to help the >situation. > > When users choose to use third party repositories they are in many cases not aware that they are not just adding packages but also replacing existing ones in their system which might be a divergence they desire. The discussions initiated by one such user along with various posting in fedora forum, user lists and irc channel is enough proof that the problem exists. Also dag, one of the third party repository packagers has essentially required the exact same thing before. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151498 Claiming that the problem is theoretical is ignoring the issue and calling it politics or FUD is not going to change that. regards Rahul From jeff.pitman at gmail.com Mon Jan 2 00:40:49 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 08:40:49 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136154793.11175.34.camel@locolhost.localdomain> References: <20051231195043.GF15058@neu.nirvana> <1136154793.11175.34.camel@locolhost.localdomain> Message-ID: <6b9c17630601011640k1d56b906t892cda731c9e5605@mail.gmail.com> On 1/2/06, Michael A. Peters wrote: > On Sat, 2005-12-31 at 20:50 +0100, Axel Thimm wrote: > > So, is there interest to have ATrpms for FC5 less overlapping with > > core packages? > > > > If so, is there any redhat.com folk that would be willing to add > > versioned obsoletes/provides to core specfiles? That's neccessary to > > ensure upgradability. > > This might not be directly on topic to what was asked. > > Is there a list for repository maintainers? Axel runs one called "repo-coord" on atrpms.net. This has been around for quite awhile. -- -jeff From florin at andrei.myip.org Mon Jan 2 01:51:35 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Sun, 01 Jan 2006 17:51:35 -0800 Subject: edit root alias when installing the OS In-Reply-To: <200601011451.42702.jarod@wilsonet.com> References: <1136149140.3230.5.camel@rivendell.home.local> <16de708d0601011423o73dea50fh23ea3edc639646a5@mail.gmail.com> <200601011451.42702.jarod@wilsonet.com> Message-ID: <1136166695.2828.8.camel@rivendell.home.local> On Sun, 2006-01-01 at 14:51 -0800, Jarod Wilson wrote: > Would probably have to be in firstrun, since there's no user accounts created > within Anaconda anymore. A simple check box for "deliver system mail to this > user" in firstboot that triggers the change ought to do the trick. That's > pretty much what SUSE has been doing for a while now. Hmmm, but I don't think that too many people configure their MUAs to slurp in the mailbox of that account. Allowing the operator to enter an arbitrary email address to receive the email from root might be more realistic. -- Florin Andrei http://florin.myip.org/ From sundaram at redhat.com Mon Jan 2 01:54:29 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 02 Jan 2006 07:24:29 +0530 Subject: edit root alias when installing the OS In-Reply-To: <1136166695.2828.8.camel@rivendell.home.local> References: <1136149140.3230.5.camel@rivendell.home.local> <16de708d0601011423o73dea50fh23ea3edc639646a5@mail.gmail.com> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> Message-ID: <43B887D5.3070505@redhat.com> Florin Andrei wrote: >On Sun, 2006-01-01 at 14:51 -0800, Jarod Wilson wrote: > > > >>Would probably have to be in firstrun, since there's no user accounts created >>within Anaconda anymore. A simple check box for "deliver system mail to this >>user" in firstboot that triggers the change ought to do the trick. That's >>pretty much what SUSE has been doing for a while now. >> >> > >Hmmm, but I don't think that too many people configure their MUAs to >slurp in the mailbox of that account. >Allowing the operator to enter an arbitrary email address to receive the >email from root might be more realistic. > > file a RFE in bugzilla against firstboot. regards Rahul From florin at andrei.myip.org Mon Jan 2 02:02:57 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Sun, 01 Jan 2006 18:02:57 -0800 Subject: edit root alias when installing the OS In-Reply-To: <43B887D5.3070505@redhat.com> References: <1136149140.3230.5.camel@rivendell.home.local> <16de708d0601011423o73dea50fh23ea3edc639646a5@mail.gmail.com> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <43B887D5.3070505@redhat.com> Message-ID: <1136167377.2938.0.camel@rivendell.home.local> On Mon, 2006-01-02 at 07:24 +0530, Rahul Sundaram wrote: > file a RFE in bugzilla against firstboot. done https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176767 -- Florin Andrei http://florin.myip.org/ From wtogami at redhat.com Mon Jan 2 04:40:42 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 01 Jan 2006 23:40:42 -0500 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> Message-ID: <43B8AECA.7040203@redhat.com> Jeff Pitman wrote: > > It could be doable. But, it would be inconsistent in some cases and > also would be a major set back as things would have to be > restructured. For example, the reason there are so many overlapping > packages between RPMforge and Extras is that the goals have diverged. > RPMforge maintains specs in a way that will make them compatible with > a wide range of distros. Extras is more of a laser-beam, > forward-looking approach. There are groups of people who fall under > the banners of either side. > > The fact of the matter is, is that the user *chose* to integrate the > third party repo into their system. The act of doing this should come > with responsibility. Protecting them will do nothing to help the > situation. > Core and Extras are under no obligation to change anything to cater to any 3rd party, although the individual package maintainers have the option of doing so if it is reasonable. Regular changes in Core and Extras are possible if they are general bug fixes. Warren Togami wtogami at redhat.com From florin at andrei.myip.org Mon Jan 2 05:55:44 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Sun, 01 Jan 2006 21:55:44 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <43B86BCE.6020302@redhat.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> Message-ID: <1136181344.2981.54.camel@rivendell.home.local> On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote: > When users choose to use third party repositories they are in many cases > not aware that they are not just adding packages but also replacing > existing ones in their system which might be a divergence they desire. > The discussions initiated by one such user along with various posting in > fedora forum, user lists and irc channel is enough proof that the > problem exists. This is currently the single most important problem with package repositories. It's the repositories hell, the vengeful progeny of the near-deceased RPM dependencies hell. -- Florin Andrei http://florin.myip.org/ From jeff.pitman at gmail.com Mon Jan 2 06:10:56 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 14:10:56 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136181344.2981.54.camel@rivendell.home.local> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> Message-ID: <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> On 1/2/06, Florin Andrei wrote: > On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote: > > > When users choose to use third party repositories they are in many cases > > not aware that they are not just adding packages but also replacing > > existing ones in their system which might be a divergence they desire. > > The discussions initiated by one such user along with various posting in > > fedora forum, user lists and irc channel is enough proof that the > > problem exists. (Offtopic: is anyone else's mail not picking up Rahul's list postings? I've seen several responses to Rahul's email, however I haven't received any from Rahul since 12/27 from fedora-devel. Odd...) > This is currently the single most important problem with package > repositories. See Warren's posting: Core/Extras has no obligation to help the situation. > It's the repositories hell, the vengeful progeny of the near-deceased > RPM dependencies hell. Not really. If it's "hell", don't use them. Pretty simple. If you'd like to help improve 3rd party repos, file bugs and/or patches to make the situation better. Also, participate in the mailing lists that the 3rd party repos have setup. And the situation is not synonymous with rpm dep hell, because with apt/yum/smart you don't have to install a random rpm and then download thirty other random rpms to satisfy deps. It's automatic. And if it's broken, see last paragraph. The issue is whether Core/Extras should protect base. Most of the 3rd party repo people have chimed in with a unanimous thumb down. Some have doubts about whether Core<->Extras migrations would work well. And only a few have given this a thumbs up with vague explanations as to why it should be default. Security being only a thin coverup for a reason. I say the idea, while it might be novel, is DOA. Especially w.r.t. to "Core/Extras has no obligations to 3rd parties". So if there is no obligation, then there is no need for protectbase. -- -jeff From admin at ramshacklestudios.com Mon Jan 2 06:43:33 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Sun, 01 Jan 2006 22:43:33 -0800 Subject: [OT] Re: ATrpms and FC5/RHEL5 In-Reply-To: <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> Message-ID: <1136184213.3483.1.camel@tuxhugger> On Mon, 2006-01-02 at 14:10 +0800, Jeff Pitman wrote: > (Offtopic: is anyone else's mail not picking up Rahul's list postings? > I've seen several responses to Rahul's email, however I haven't > received any from Rahul since 12/27 from fedora-devel. Odd...) I seem to be receiving them okay. Have you checked the relevant logs? Perhaps the messages may have been mistakenly marked as Junk or similar? :-/ -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 -------------- 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 florin at andrei.myip.org Mon Jan 2 06:44:36 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Sun, 01 Jan 2006 22:44:36 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> Message-ID: <1136184276.2981.66.camel@rivendell.home.local> On Mon, 2006-01-02 at 14:10 +0800, Jeff Pitman wrote: > On 1/2/06, Florin Andrei wrote: > > It's the repositories hell, the vengeful progeny of the near-deceased > > RPM dependencies hell. > > Not really. If it's "hell", don't use them. Pretty simple. Right, so repository XYZ carries the package ABC, which I need, but since XYZ fosters the repo hell, I shall simply walk away whistling. Makes no sense to me, really. The concept of package repositories is a very powerful one, but this current situation is crippling. Fedora per se, plus Extras, is nice, solid and coherent. Fedora plus the repositories ecosystem is currently an entity with a serious multiple personality disorder. > And the situation is not synonymous with rpm dep hell, because with > apt/yum/smart you don't have to install a random rpm and then download > thirty other random rpms to satisfy deps. I didn't say it's synonymous. But it can be equally frustrating. Or more. Such as, enable repo XYZ, do a "yum update", get a broken system ("broken" as in "does not work anymore with any other repo, and XYZ must be perpetually used from now on otherwise funky things happen"). Do not pass Go, do not collect $200. > The issue is whether Core/Extras should protect base. Most of the 3rd > party repo people have chimed in with a unanimous thumb down. 3rd party repos have no business fiddling with the core packages, since that is the root cause of the repo hell. It boggles the mind that this is not a self-evident truth. -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Mon Jan 2 06:47:03 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Sun, 01 Jan 2006 22:47:03 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136156708.11175.37.camel@locolhost.localdomain> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <1136156708.11175.37.camel@locolhost.localdomain> Message-ID: <1136184423.2981.69.camel@rivendell.home.local> On Sun, 2006-01-01 at 15:05 -0800, Michael A. Peters wrote: > The problem is there are a fair number of packages that are not > overlapping but depend upon overlapping. So it really is difficult if > you have a sizeable repository like Axel does. My feeling is that 95% of all those "not overlapping but dependent" cases can be avoided with a healthy dose of common sense. Such as, less aggressive tracking of new releases, etc. -- Florin Andrei http://florin.myip.org/ From jeff.pitman at gmail.com Mon Jan 2 06:49:47 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 14:49:47 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136184276.2981.66.camel@rivendell.home.local> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <1136184276.2981.66.camel@rivendell.home.local> Message-ID: <6b9c17630601012249w473c53e6s8fcdf26c2db48ab1@mail.gmail.com> All I see is a rant and a censoring of my statement about how you can contribute to the 3rd party repository. Remember: "Core/Extras has no obligation" to help 3rd party repos or enforce a world-wide policy. That's up to you. And, that's why /etc/yum.repos.d isn't populated with 3rd party repos by default. On 1/2/06, Florin Andrei wrote: > On Mon, 2006-01-02 at 14:10 +0800, Jeff Pitman wrote: > > On 1/2/06, Florin Andrei wrote: > > > > It's the repositories hell, the vengeful progeny of the near-deceased > > > RPM dependencies hell. > > > > Not really. If it's "hell", don't use them. Pretty simple. > > Right, so repository XYZ carries the package ABC, which I need, but > since XYZ fosters the repo hell, I shall simply walk away whistling. > > Makes no sense to me, really. The concept of package repositories is a > very powerful one, but this current situation is crippling. > > Fedora per se, plus Extras, is nice, solid and coherent. > Fedora plus the repositories ecosystem is currently an entity with a > serious multiple personality disorder. > > > And the situation is not synonymous with rpm dep hell, because with > > apt/yum/smart you don't have to install a random rpm and then download > > thirty other random rpms to satisfy deps. > > I didn't say it's synonymous. But it can be equally frustrating. Or > more. Such as, enable repo XYZ, do a "yum update", get a broken system > ("broken" as in "does not work anymore with any other repo, and XYZ must > be perpetually used from now on otherwise funky things happen"). Do not > pass Go, do not collect $200. > > > The issue is whether Core/Extras should protect base. Most of the 3rd > > party repo people have chimed in with a unanimous thumb down. > > 3rd party repos have no business fiddling with the core packages, since > that is the root cause of the repo hell. It boggles the mind that this > is not a self-evident truth. > > -- > Florin Andrei > > http://florin.myip.org/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- -jeff From sundaram at redhat.com Mon Jan 2 06:50:43 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 02 Jan 2006 12:20:43 +0530 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> Message-ID: <43B8CD43.6080201@redhat.com> Jeff Pitman wrote: >On 1/2/06, Florin Andrei wrote: > > >>On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote: >> >> >> >>>When users choose to use third party repositories they are in many cases >>>not aware that they are not just adding packages but also replacing >>>existing ones in their system which might be a divergence they desire. >>>The discussions initiated by one such user along with various posting in >>>fedora forum, user lists and irc channel is enough proof that the >>>problem exists. >>> >>> > >(Offtopic: is anyone else's mail not picking up Rahul's list postings? >I've seen several responses to Rahul's email, however I haven't >received any from Rahul since 12/27 from fedora-devel. Odd...) > > Maybe you put me in the killfile for making too much noise?. Thats entirely possible. You might not receive this anyway regards Rahul From jeff.pitman at gmail.com Mon Jan 2 06:51:42 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 14:51:42 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136184423.2981.69.camel@rivendell.home.local> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <1136156708.11175.37.camel@locolhost.localdomain> <1136184423.2981.69.camel@rivendell.home.local> Message-ID: <6b9c17630601012251t1727bb45oa03f6f7c30a43603@mail.gmail.com> On 1/2/06, Florin Andrei wrote: > On Sun, 2006-01-01 at 15:05 -0800, Michael A. Peters wrote: > > > The problem is there are a fair number of packages that are not > > overlapping but depend upon overlapping. So it really is difficult if > > you have a sizeable repository like Axel does. > > My feeling is that 95% of all those "not overlapping but dependent" > cases can be avoided with a healthy dose of common sense. Such as, less > aggressive tracking of new releases, etc. If you want less aggressive tracking, don't use 3rd party and/or use distro that matches this policy (eg. use CentOS instead). -- -jeff From jeff.pitman at gmail.com Mon Jan 2 07:03:19 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 15:03:19 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <43B8CD43.6080201@redhat.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <43B8CD43.6080201@redhat.com> Message-ID: <6b9c17630601012303q1d5ad84ds1224293a7f76adec@mail.gmail.com> On 1/2/06, Rahul Sundaram wrote: > Maybe you put me in the killfile for making too much noise?. Thats > entirely possible. You might not receive this anyway Heh, gmail is marking you and several others as Spam. I don't silence anyone, by choice. :P -- -jeff From jeff.pitman at gmail.com Mon Jan 2 07:08:08 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 15:08:08 +0800 Subject: FC5 and Yum Plugins In-Reply-To: <43B4A3C4.7080407@redhat.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> Message-ID: <6b9c17630601012308q4bcbb5aagd9e0e25b1dc8f51a@mail.gmail.com> (just resurrected from the spam bucket...) On 12/30/05, Rahul Sundaram wrote: > So would third party repository maintainers consider Fedora Core having > protectbase by enabled acceptable?. Would it better to document the > exist the functionality provided by protectbase plugin within the Fedora > release notes and let users configure it for themselves? Yes. Since adding the 3rd party repo was by choice, then protecting base should be as well. I would have no problem with Core/Extras including it and documenting it. -- -jeff From jkeating at j2solutions.net Mon Jan 2 02:56:02 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 01 Jan 2006 18:56:02 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <43B86BCE.6020302@redhat.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> Message-ID: <1136170562.3002.2.camel@yoda.loki.me> On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote: > When users choose to use third party repositories they are in many cases > not aware that they are not just adding packages but also replacing > existing ones in their system which might be a divergence they desire. > The discussions initiated by one such user along with various posting in > fedora forum, user lists and irc channel is enough proof that the > problem exists. Also dag, one of the third party repository packagers > has essentially required the exact same thing before. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151498 > > Claiming that the problem is theoretical is ignoring the issue and > calling it politics or FUD is not going to change that. Have we thought about maybe an 'installonly' type plugin for 3rd party repos? Only allow the installation of packages from that repo, exclude it from generic 'update' calls, or only allow packages that have been installed from said repo to be updated from said repo (and specific deps)? This would allow users to install specific package sets and avoid generic update issues. I tried to install some mono stuff from nrpms, left nrpms configured and did a yum update and was prompted to update a very large amount of my core over to nrpms versions of packages. Not cool. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 dennis at ausil.us Mon Jan 2 07:09:40 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 2 Jan 2006 01:09:40 -0600 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <20051231195043.GF15058@neu.nirvana> References: <20051231195043.GF15058@neu.nirvana> Message-ID: <200601020109.46712.dennis@ausil.us> Once upon a time Saturday 31 December 2005 1:50 pm, Axel Thimm wrote: > So, is there interest to have ATrpms for FC5 less overlapping with > core packages? > > If so, is there any redhat.com folk that would be willing to add > versioned obsoletes/provides to core specfiles? That's neccessary to > ensure upgradability. I think that the best option would be to write a series of scripts the you can run before upgrade that will remove all of the third party packages and create a script for post install that will reinstall the packages removed. if you are not going to replace core packages anymore then that should work nicely. The recomendation should be the same for an upgrade as those made for ximian packages. The only issues i see with this is 1. you have replaced core packages that break dependancies, in which case a downgrade would be needed. 2. if 3rd party rpms that replace core funcionality are not removed the system upgrade could fail if new core package version-release is less that third party package. All that can be done if bugs filed if packages decide to add obsoletes/provides then thats there choice -- Dennis Gilmore, RHCE http://www.ausil.us From florin at andrei.myip.org Mon Jan 2 07:13:20 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Sun, 01 Jan 2006 23:13:20 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <6b9c17630601012251t1727bb45oa03f6f7c30a43603@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <1136156708.11175.37.camel@locolhost.localdomain> <1136184423.2981.69.camel@rivendell.home.local> <6b9c17630601012251t1727bb45oa03f6f7c30a43603@mail.gmail.com> Message-ID: <1136186000.2981.72.camel@rivendell.home.local> On Mon, 2006-01-02 at 14:51 +0800, Jeff Pitman wrote: > On 1/2/06, Florin Andrei wrote: > > On Sun, 2006-01-01 at 15:05 -0800, Michael A. Peters wrote: > > > > > The problem is there are a fair number of packages that are not > > > overlapping but depend upon overlapping. So it really is difficult if > > > you have a sizeable repository like Axel does. > > > > My feeling is that 95% of all those "not overlapping but dependent" > > cases can be avoided with a healthy dose of common sense. Such as, less > > aggressive tracking of new releases, etc. > > If you want less aggressive tracking, don't use 3rd party and/or use > distro that matches this policy (eg. use CentOS instead). I feel a communications breakdown here. I was speaking about less aggressive version tracking in 3rd party repos with Fedora. And "don't use 3rd party" is so bogus I'm not even going to debunk it. -- Florin Andrei http://florin.myip.org/ From jeff.pitman at gmail.com Mon Jan 2 07:15:36 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 15:15:36 +0800 Subject: Gmail Marking Random Fedora mail as SPAM (was Re: ATrpms and FC5/RHEL5) Message-ID: <6b9c17630601012315v4ec7a4a8gb718f94320989e31@mail.gmail.com> Hi, Since 12/24/2005, random emails have been falsely identified as spam in gmail from Fedora Devel list. This is just an FYI if you are collecting emails in gmail and/or using it directly. (Though, I might be the only one affected... :P) On 1/2/06, Rahul Sundaram wrote: > Jeff Pitman wrote: > >(Offtopic: is anyone else's mail not picking up Rahul's list postings? > >I've seen several responses to Rahul's email, however I haven't > >received any from Rahul since 12/27 from fedora-devel. Odd...) > Maybe you put me in the killfile for making too much noise?. Thats > entirely possible. You might not receive this anyway -- -jeff From jeff.pitman at gmail.com Mon Jan 2 07:25:47 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 15:25:47 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136186000.2981.72.camel@rivendell.home.local> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <1136156708.11175.37.camel@locolhost.localdomain> <1136184423.2981.69.camel@rivendell.home.local> <6b9c17630601012251t1727bb45oa03f6f7c30a43603@mail.gmail.com> <1136186000.2981.72.camel@rivendell.home.local> Message-ID: <6b9c17630601012325ua7f0ca5x94f213234803304f@mail.gmail.com> On 1/2/06, Florin Andrei wrote: > And "don't use 3rd party" is so bogus I'm not even going to debunk it. It basically comes down to this, if a 3rd party is not doing something you like: 1. Communicate what's wrong on the 3rd party's mailing list. (Not on fedora's.) 2. Offer specs, patches, mechanisms, or scripts via 3rd party's mailing list and/or bugtracker. If that fails to alter the course of the 3rd party repo into a direction you like, then you have the following choices: 1. Don't use the 3rd party repo. 2. Fork it and create your own. 3. Import packages into a repo that caters to your policies. 4. Rant about it randomly. Anyway, this is all way off topic. The conclusion of this thread is: If there is a 3rd party repo having difficulty integrating with Core/Extras because of a Versioned Obsoletes problem, then hang a bugzilla for that specific package. Otherwise, Core/Extras has no obligation to take on a massive undertaking that would cater to 3rd party repositories. That's it. -- -jeff From jeff.pitman at gmail.com Mon Jan 2 07:36:44 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 15:36:44 +0800 Subject: Royalty free gstreamer plug-in In-Reply-To: <43B1393E.5070601@laPoste.net> References: <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> <43B1393E.5070601@laPoste.net> Message-ID: <6b9c17630601012336g662ba4eeoabea8a2ffaf0bf5b@mail.gmail.com> On 12/27/05, Nicolas Mailhot wrote: > Jeff Pitman a ?crit : > > > Let's not forget that the "holier-than-thou" stance alienates quite a few users. > > And the permissive attitude of some distributions alienate others. > Fedora has to take one side on the IP rights debate. And no matter > which one is it, people on the other side will be "alienated" by this > choice. > > I don't think we need another Mandriva/Linspire in the Linux world. I was actually thinking more along the lines of Ubuntu. Universe is commented out in sources.list and it is extremely well documented on how to get MP3 activated. The same can be done here. -- -jeff From buildsys at redhat.com Mon Jan 2 08:01:28 2006 From: buildsys at redhat.com (Build System) Date: Mon, 2 Jan 2006 03:01:28 -0500 Subject: rawhide report: 20060102 changes Message-ID: <200601020801.k0281SP4015860@porkchop.devel.redhat.com> Updated Packages: iso-codes-0.49-1 ---------------- * Sun Jan 01 2006 Christopher Aillon 0.49-1 - Update to 0.49 kernel-2.6.14-1.1807_FC5 ------------------------ * Sun Jan 01 2006 Dave Jones - 2.6.15-rc7-git6 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5smp jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) From mpeters at mac.com Mon Jan 2 08:23:14 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 02 Jan 2006 00:23:14 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136184276.2981.66.camel@rivendell.home.local> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <1136184276.2981.66.camel@rivendell.home.local> Message-ID: <1136190194.11175.75.camel@locolhost.localdomain> On Sun, 2006-01-01 at 22:44 -0800, Florin Andrei wrote: > On Mon, 2006-01-02 at 14:10 +0800, Jeff Pitman wrote: > > On 1/2/06, Florin Andrei wrote: > > > > It's the repositories hell, the vengeful progeny of the near-deceased > > > RPM dependencies hell. > > > > Not really. If it's "hell", don't use them. Pretty simple. > > Right, so repository XYZ carries the package ABC, which I need, but > since XYZ fosters the repo hell, I shall simply walk away whistling. > > Makes no sense to me, really. The concept of package repositories is a > very powerful one, but this current situation is crippling. The situation is crippling imho only because a newer EVR will always be chosen by yum, which I think *could* be improved - wether it is Fedora's responsibility to or not. > *snip* > > 3rd party repos have no business fiddling with the core packages, since > that is the root cause of the repo hell. It boggles the mind that this > is not a self-evident truth. There are times when it is a must. In order to use Package C you may need core Package A linked against something that core package A isn't linked against. In the past I would rebuild the gd library with gif support on my own system so that I could build php with gif support. That's no longer needed. In the past I would rebuild the libtiff library with lzw support. That also is no longer needed. I still rebuild sox with mp3 support because I have not (yet) found a suitable swiss army knife type of easily scriptable tool for recording an input stream and encoding straight to mp3. Might be able to do it with gstreamer pipes, but sox just does it. Those are *my* personal needs that cause(d) me to replace core packages. I'm sure others have similar situations, and these third party repo's fill those needs - sometimes as dependencies. That is a service to the Fedora community that sometimes Fedora itself can't fill due to patent/licensing issues etc. If instead of just looking at EVR yum could look at DPEVR where D is dependency, P is repository priority, things might be better. D would be by default 0 - and incremented for each dependency in the transaction it fulfills. For example - if atrpms had sox with mp3 support that had : provides: sox-mp3 - then yum could figure out that when sox-mp3 is required, to bump the D for the atrpms sox package causing it to replace the core sox package BUT ONLY if the sox-mp3 is required by something. The core sox package would provide sox and thus have a D of one, but the atrpms sox would provide both sox and sox-mp3 and thus have a D value of 2 so it would have priority. That may be a dumb way to do it, not well thought out, but anyway ... The P could be a priority setting that is inherited from a repository global priority but can be over-ridden on a per package basis. Thus I could have rpm.livna.org have a higher global priority than atrpms - but give the gstreamer plugins in atrpms higher individual priority than livna, for example. P would only be used if the D value were the same. If the P and D value is the same, then EVR is used. Right now only EVR is used. The problem is that rpm does not store in its database repository information so figuring out P for installed packages is difficult, though that potentially could be figured out from GPG sig - under the big (false) assumption that each repository only uses one GPG key (rawhide has a couple, and some are sometimes not signed at all) From mpeters at mac.com Mon Jan 2 08:31:11 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 02 Jan 2006 00:31:11 -0800 Subject: Gmail Marking Random Fedora mail as SPAM (was Re: ATrpms and FC5/RHEL5) In-Reply-To: <6b9c17630601012315v4ec7a4a8gb718f94320989e31@mail.gmail.com> References: <6b9c17630601012315v4ec7a4a8gb718f94320989e31@mail.gmail.com> Message-ID: <1136190671.11175.77.camel@locolhost.localdomain> On Mon, 2006-01-02 at 15:15 +0800, Jeff Pitman wrote: > Hi, > > Since 12/24/2005, random emails have been falsely identified as spam > in gmail from Fedora Devel list. This is just an FYI if you are > collecting emails in gmail and/or using it directly. (Though, I might > be the only one affected... :P) Ouch. I use gmail for some lists - guess that needs to change. From jeff.pitman at gmail.com Mon Jan 2 08:33:54 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 16:33:54 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136190194.11175.75.camel@locolhost.localdomain> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <1136184276.2981.66.camel@rivendell.home.local> <1136190194.11175.75.camel@locolhost.localdomain> Message-ID: <6b9c17630601020033x3e4e8a90g2b40d0aebe7dd735@mail.gmail.com> On 1/2/06, Michael A. Peters wrote: > If instead of just looking at EVR yum could look at DPEVR where D is > dependency, P is repository priority, things might be better. You know that depsolve is mostly delegated to rpmlib, right? > [cut ... Explanation for a possible solution ... cut] I think it will come down to this ... use yum for Core/Extras and where default behavior of a 3rd party repo is acceptable to you. Otherwise, use smart for any other weird, magic, bit-twiddling behavior needs. If a plugin can provide the solution you layed out, then by all means, provide it. I highly doubt the proposed solution will go into yum proper. -- -jeff From jeff.pitman at gmail.com Mon Jan 2 08:35:20 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 16:35:20 +0800 Subject: Gmail Marking Random Fedora mail as SPAM (was Re: ATrpms and FC5/RHEL5) In-Reply-To: <1136190671.11175.77.camel@locolhost.localdomain> References: <6b9c17630601012315v4ec7a4a8gb718f94320989e31@mail.gmail.com> <1136190671.11175.77.camel@locolhost.localdomain> Message-ID: <6b9c17630601020035x13cc40d1q72f092f94fadb1a9@mail.gmail.com> On 1/2/06, Michael A. Peters wrote: > On Mon, 2006-01-02 at 15:15 +0800, Jeff Pitman wrote: > > Hi, > > > > Since 12/24/2005, random emails have been falsely identified as spam > > in gmail from Fedora Devel list. This is just an FYI if you are > > collecting emails in gmail and/or using it directly. (Though, I might > > be the only one affected... :P) > > Ouch. > I use gmail for some lists - guess that needs to change. "is:spam listname" in the search box to verify. It may have been isolated problem. I don't know. -- -jeff From mpeters at mac.com Mon Jan 2 08:36:02 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 02 Jan 2006 00:36:02 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <1136118287.2669.5.camel@localhost.localdomain> References: <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> <3adc77210512310757p3115c13buf10b3a6198c95c8b@mail.gmail.com> <604aa7910512310849t4217a176ne884326b12ec0d15@mail.gmail.com> <1136049422.3516.166.camel@pmac.infradead.org> <20051231183147.GA15058@neu.nirvana> <1136104872.11175.9.camel@locolhost.localdomain> <1136118287.2669.5.camel@localhost.localdomain> Message-ID: <1136190962.11175.83.camel@locolhost.localdomain> On Sun, 2006-01-01 at 13:24 +0100, Thorsten Leemhuis wrote: > > I agree -- IMHO audacity in livna should be renamed to audacity-mp3 (or > something else, no better idea atm) and conflict with audacity from > extras. That way people can uninstall audacity from extras and manually > install the version from livna if they want to (maybe it also works with > some obsolete-magic, but I don't think so and did not try). > > Michael, could you file a bug in livna's bugzilla? tia Sure - but if it was up to me, I'd just leave it and let users who need one or not the other use exclude in the repo file. I wonder how Marlin is coming along ... it uses plugins :) From peter.bieshaar at gmail.com Mon Jan 2 08:37:38 2006 From: peter.bieshaar at gmail.com (Peter Bieshaar) Date: Mon, 2 Jan 2006 09:37:38 +0100 Subject: Gmail Marking Random Fedora mail as SPAM (was Re: ATrpms and FC5/RHEL5) In-Reply-To: <1136190671.11175.77.camel@locolhost.localdomain> References: <6b9c17630601012315v4ec7a4a8gb718f94320989e31@mail.gmail.com> <1136190671.11175.77.camel@locolhost.localdomain> Message-ID: <529f9df20601020037j648d0000x@mail.gmail.com> No you aren't the only one affected. I counldn't find out what's the criteria of being spam. But this is a gmail problem imho. 2006/1/2, Michael A. Peters : > > On Mon, 2006-01-02 at 15:15 +0800, Jeff Pitman wrote: > > Hi, > > > > Since 12/24/2005, random emails have been falsely identified as spam > > in gmail from Fedora Devel list. This is just an FYI if you are > > collecting emails in gmail and/or using it directly. (Though, I might > > be the only one affected... :P) > > Ouch. > I use gmail for some lists - guess that needs to change. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Peter Bieshaar NL(0)6 29577255 -------------- next part -------------- An HTML attachment was scrubbed... URL: From n0dalus+redhat at gmail.com Mon Jan 2 09:06:30 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Mon, 2 Jan 2006 19:36:30 +1030 Subject: Gmail Marking Random Fedora mail as SPAM (was Re: ATrpms and FC5/RHEL5) In-Reply-To: <1136190671.11175.77.camel@locolhost.localdomain> References: <6b9c17630601012315v4ec7a4a8gb718f94320989e31@mail.gmail.com> <1136190671.11175.77.camel@locolhost.localdomain> Message-ID: <6280325c0601020106j7885965ci384fa3b2124a8611@mail.gmail.com> On 1/2/06, Michael A. Peters wrote: > On Mon, 2006-01-02 at 15:15 +0800, Jeff Pitman wrote: > > Hi, > > > > Since 12/24/2005, random emails have been falsely identified as spam > > in gmail from Fedora Devel list. This is just an FYI if you are > > collecting emails in gmail and/or using it directly. (Though, I might > > be the only one affected... :P) > > Ouch. > I use gmail for some lists - guess that needs to change. > This email got marked as spam in my gmail. I wonder if this has anything to do with the 'Precedence: junk' header that redhat adds. It has only happened to a few emails for me. n0dalus. From jeff.pitman at gmail.com Mon Jan 2 09:10:15 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 2 Jan 2006 17:10:15 +0800 Subject: Gmail Marking Random Fedora mail as SPAM (was Re: ATrpms and FC5/RHEL5) In-Reply-To: <6280325c0601020106j7885965ci384fa3b2124a8611@mail.gmail.com> References: <6b9c17630601012315v4ec7a4a8gb718f94320989e31@mail.gmail.com> <1136190671.11175.77.camel@locolhost.localdomain> <6280325c0601020106j7885965ci384fa3b2124a8611@mail.gmail.com> Message-ID: <6b9c17630601020110l64afe2d6n11b18566cc652eba@mail.gmail.com> FYI-- I've reported this. If I hear anything, I'll let you know. On 1/2/06, n0dalus wrote: > On 1/2/06, Michael A. Peters wrote: > > On Mon, 2006-01-02 at 15:15 +0800, Jeff Pitman wrote: > > > Hi, > > > > > > Since 12/24/2005, random emails have been falsely identified as spam > > > in gmail from Fedora Devel list. This is just an FYI if you are > > > collecting emails in gmail and/or using it directly. (Though, I might > > > be the only one affected... :P) > > > > Ouch. > > I use gmail for some lists - guess that needs to change. > > > > This email got marked as spam in my gmail. > > I wonder if this has anything to do with the 'Precedence: junk' header > that redhat adds. It has only happened to a few emails for me. > > n0dalus. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- -jeff From mpeters at mac.com Mon Jan 2 10:37:47 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 02 Jan 2006 02:37:47 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <6b9c17630601020033x3e4e8a90g2b40d0aebe7dd735@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <1136184276.2981.66.camel@rivendell.home.local> <1136190194.11175.75.camel@locolhost.localdomain> <6b9c17630601020033x3e4e8a90g2b40d0aebe7dd735@mail.gmail.com> Message-ID: <1136198267.11175.96.camel@locolhost.localdomain> On Mon, 2006-01-02 at 16:33 +0800, Jeff Pitman wrote: > On 1/2/06, Michael A. Peters wrote: > > If instead of just looking at EVR yum could look at DPEVR where D is > > dependency, P is repository priority, things might be better. > > You know that depsolve is mostly delegated to rpmlib, right? Yup - and that's a problem. > > > [cut ... Explanation for a possible solution ... cut] > > I think it will come down to this ... use yum for Core/Extras and > where default behavior of a 3rd party repo is acceptable to you. > Otherwise, use smart for any other weird, magic, bit-twiddling > behavior needs. But if smart can do it - yum could potentially be taught to do it as well. > > If a plugin can provide the solution you layed out, then by all means, > provide it. I highly doubt the proposed solution will go into yum > proper. Not anytime soon. I'm guessing though it would require yum to keep a database of its own to know what came from where - which would be way to fragile because anything not installed by yum would not be in there. So unless yum has another way to figure out what packages come from where, it probably is never going to be optimal and therefore never implemented. From mpeters at mac.com Mon Jan 2 10:41:44 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 02 Jan 2006 02:41:44 -0800 Subject: edit root alias when installing the OS In-Reply-To: <1136150058.3376.13.camel@tuxhugger> References: <1136149140.3230.5.camel@rivendell.home.local> <1136150058.3376.13.camel@tuxhugger> Message-ID: <1136198504.11175.101.camel@locolhost.localdomain> On Sun, 2006-01-01 at 13:14 -0800, Peter Gordon wrote: > On Sun, 2006-01-01 at 12:59 -0800, Florin Andrei wrote: > > Wouldn't make sense to edit /etc/aliases while installing the OS and ask > > the operator to provide a real email as an alias? > > It is a very common error to forget the root alias. As a result, the > > email sent by housekeeping software (such as logwatch) is ignored, often > > with unpleasant results. > > > > https://www.redhat.com/archives/fedora-list/2006-January/thread.html#00045 > > > > This may or may not require to edit the relayhost variable in the MTA > > (ask the operator to provide a default mail relay), I'm not sure > > (depending on how "correct" or thorough the installer should be). > > That sounds like a good idea to me. Perhaps it could default to aliasing > root to the user created during firstboot, or something similar? It should go to a local user and it should ask which local user. root always should go to a local user, and if needed, the local user can then forward to somewhere else - but it should go to a local user first so that if there is a problem delivering, you don't end up with a loop to the root account. If the user wants them forwarded to an e-mail address not on local host, they can configure that themselves post install. Evolution picks up mail sent to the local user just fine. From jos at xos.nl Mon Jan 2 10:46:41 2006 From: jos at xos.nl (Jos Vos) Date: Mon, 2 Jan 2006 11:46:41 +0100 Subject: edit root alias when installing the OS In-Reply-To: <1136198504.11175.101.camel@locolhost.localdomain>; from mpeters@mac.com on Mon, Jan 02, 2006 at 02:41:44AM -0800 References: <1136149140.3230.5.camel@rivendell.home.local> <1136150058.3376.13.camel@tuxhugger> <1136198504.11175.101.camel@locolhost.localdomain> Message-ID: <20060102114641.A4169@xos037.xos.nl> On Mon, Jan 02, 2006 at 02:41:44AM -0800, Michael A. Peters wrote: > It should go to a local user and it should ask which local user. > root always should go to a local user, and if needed, the local user can > then forward to somewhere else - but it should go to a local user first > so that if there is a problem delivering, you don't end up with a loop > to the root account. At installation time, there is no local user, only after "firstboot". -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From mpeters at mac.com Mon Jan 2 11:03:46 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 02 Jan 2006 03:03:46 -0800 Subject: edit root alias when installing the OS In-Reply-To: <20060102114641.A4169@xos037.xos.nl> References: <1136149140.3230.5.camel@rivendell.home.local> <1136150058.3376.13.camel@tuxhugger> <1136198504.11175.101.camel@locolhost.localdomain> <20060102114641.A4169@xos037.xos.nl> Message-ID: <1136199826.17625.0.camel@locolhost.localdomain> On Mon, 2006-01-02 at 11:46 +0100, Jos Vos wrote: > > At installation time, there is no local user, only after "firstboot". Yeah, that's what I meant. From emmanuel.seyman at club-internet.fr Mon Jan 2 11:10:55 2006 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 2 Jan 2006 12:10:55 +0100 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136184276.2981.66.camel@rivendell.home.local> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <1136184276.2981.66.camel@rivendell.home.local> Message-ID: <20060102111055.GA6671@orient.maison.moi> On Sun, Jan 01, 2006 at 10:44:36PM -0800, Florin Andrei wrote: > > Right, so repository XYZ carries the package ABC, which I need, but > since XYZ fosters the repo hell, I shall simply walk away whistling. The correct thing to do would be to: 1) Complain to the repo maintainer that replacing Core (and Extras?) packages is a big no-no. 2) Find out why said repo maintainer feels the need to replace said packages 3) Submit a bug in Bugzilla to solve repo maintainer's need 4) Wait for bug to be resolved. Wait for repo maintainer to rebuild packages that don't conflict with Core/Extras anymore. > 3rd party repos have no business fiddling with the core packages, since > that is the root cause of the repo hell. It boggles the mind that this > is not a self-evident truth. The problem isn't telling them this, it's finding out why it's happening and how to prevent it. Fight the cause, not the symptom. Emmanuel From ivg2 at cornell.edu Mon Jan 2 09:38:08 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 04:38:08 -0500 Subject: "GUI gadgets", was: Fedora meeting Mono Half-Way In-Reply-To: <1134741282.2764.7.camel@wombat.tiptoe.de> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <43A1A782.8000506@cornell.edu> <1134725344.11167.5.camel@wombat.tiptoe.de> <43A299E9.2080802@cornell.edu> <1134741282.2764.7.camel@wombat.tiptoe.de> Message-ID: <43B8F480.3020201@cornell.edu> > Can you open a BZ for this one? Please make a copy of your /etc/passwd, > group, shadow, gshadow files, edit out any (real) passwords and attach > them (marked as private) to that bug. > My password files are not relevant - yes, the tomcat4 user has a password in shadow, and no entry in passwd (probably I erased it manually a long time ago). Yes, this is a configuration problem, but I think the program should warn about it and skip that user, instead of refusing to work altogether. Let me know if you still want a bugzilla. From igorm5 at vip.hr Mon Jan 2 13:08:48 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Mon, 02 Jan 2006 14:08:48 +0100 Subject: http://conky.sourceforge.net/ Message-ID: <43B925E0.9070001@vip.hr> http://conky.sourceforge.net/ Seems great monitoring program, but I can't compile it :-/ If it is stable, it would be very nice if you include it into Fedora Extras. If someone knows for some rpm package for Fedora, just let me know. Cheers! -- Igor Jagec From stickster at gmail.com Mon Jan 2 14:08:33 2006 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 02 Jan 2006 09:08:33 -0500 Subject: Gmail problems In-Reply-To: <6b9c17630601012303q1d5ad84ds1224293a7f76adec@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <43B8CD43.6080201@redhat.com> <6b9c17630601012303q1d5ad84ds1224293a7f76adec@mail.gmail.com> Message-ID: <1136210913.30809.2.camel@localhost.localdomain> On Mon, 2006-01-02 at 15:03 +0800, Jeff Pitman wrote: > On 1/2/06, Rahul Sundaram wrote: > > Maybe you put me in the killfile for making too much noise?. Thats > > entirely possible. You might not receive this anyway > > Heh, gmail is marking you and several others as Spam. I don't silence > anyone, by choice. :P WORKSFORME Don't know if this will help or hinder tracking the problem, but I seem to be receiving all list mail just fine. I was actually just checking my spam box on Gmail yesterday and the day before, and saw no anomalies. I'm seeing all of Rahul's mail in particular, FWIW. Is this worth tracking data points somehow? If so, how? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 ivg2 at cornell.edu Mon Jan 2 13:33:47 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 08:33:47 -0500 Subject: Patterned slow-down over the entire GNOME desktop Message-ID: <43B92BBB.9050909@cornell.edu> Hi, I am experiencing slow-down over the entire GNOME desktop. It is interesting - 100% CPU activity for a very long time (too long for everything to be allright). What seems interesting to me is that the slowdown occurs in a pattern - every second time I start up the app it is slow, so run1:slow, run2:fast, run3:slow, run4:fast, regardless of timing. Further, this is a multi app pattern. Start up appX: slow, appY:fast, appZ:slow, appXX:fast. It also happens if you start up multiple copies of the same app: copy1:slow, copy2:fast, copy3:slow. Does not occur with multiple firefox windows, or multiple terminals, which will start up very fast if there's a single one open. Does not occur with something like xpdf - only gnome apps. Suggestions? What's the correct bugzilla component? From fedora at camperquake.de Mon Jan 2 15:37:42 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 2 Jan 2006 16:37:42 +0100 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B92BBB.9050909@cornell.edu> References: <43B92BBB.9050909@cornell.edu> Message-ID: <20060102153742.GA11754@ryoko.camperquake.de> On Mon, Jan 02, 2006 at 08:33:47AM -0500, Ivan Gyurdiev wrote: > Hi, I am experiencing slow-down over the entire GNOME desktop. It is > interesting - 100% CPU activity for a very long time (too long for > everything to be allright). DaveJ mentioned that recent FC kernels have memory usage tracking enabled, which may slow down some processes considerably. You may be seeing this. This will not be present in later kernels. From sundaram at redhat.com Mon Jan 2 15:40:00 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 02 Jan 2006 21:10:00 +0530 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B92BBB.9050909@cornell.edu> References: <43B92BBB.9050909@cornell.edu> Message-ID: <43B94950.9050403@redhat.com> Ivan Gyurdiev wrote: > Hi, I am experiencing slow-down over the entire GNOME desktop. It is > interesting - 100% CPU activity for a very long time (too long for > everything to be allright). What seems interesting to me is that the > slowdown occurs in a pattern - every second time I start up the app it > is slow, so run1:slow, run2:fast, run3:slow, run4:fast, regardless of > timing. Further, this is a multi app pattern. Start up appX: slow, > appY:fast, appZ:slow, appXX:fast. It also happens if you start up > multiple copies of the same app: copy1:slow, copy2:fast, copy3:slow. > Does not occur with multiple firefox windows, or multiple terminals, > which will start up very fast if there's a single one open. Does not > occur with something like xpdf - only gnome apps. > > Suggestions? What's the correct bugzilla component? > See http://www.livejournal.com/users/kernelslacker/32574.html. People who are interested in following Fedora related blogs and development might read http://fedoraproject.org/people/ regards Rahul From ivg2 at cornell.edu Mon Jan 2 13:51:36 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 08:51:36 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <20060102153742.GA11754@ryoko.camperquake.de> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> Message-ID: <43B92FE8.2080702@cornell.edu> > DaveJ mentioned that recent FC kernels have memory usage tracking enabled, > which may slow down some processes considerably. You may be seeing this. > This will not be present in later kernels. > How does that explain the patterned behavior? Also, I still run kernel 1688, because I don't want to deal with the hassle of making the livna nvidia driver work with modular X for every new kernel. Which kernel started including this tracking patch? From arjan at fenrus.demon.nl Mon Jan 2 16:07:54 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 02 Jan 2006 17:07:54 +0100 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B92FE8.2080702@cornell.edu> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> Message-ID: <1136218074.2936.34.camel@laptopd505.fenrus.org> > Also, I still run kernel 1688, because I don't want to deal with the > hassle of making the livna nvidia driver work with modular X for every > new kernel. Which kernel started including this tracking patch oh you're using the binary nvidia driver; would maybe have been useful to give info like that in the initial report ;) (eg what hardware is involved, what kernel stuff what X stuff etc etc) From vonbrand at inf.utfsm.cl Mon Jan 2 16:19:57 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 02 Jan 2006 13:19:57 -0300 Subject: FC5 and Yum Plugins In-Reply-To: Your message of "Thu, 29 Dec 2005 21:52:06 BST." <20051229205206.GG4833@neu.nirvana> Message-ID: <200601021619.k02GJvZx010378@laptop11.inf.utfsm.cl> Axel Thimm wrote: > On Thu, Dec 29, 2005 at 03:28:34PM -0500, Jeff Spaleta wrote: > > I think protectbase by default is a particularly bad idea for a > > number of reasons. But if i understand the original poster > > correctly, the problem he wants solved is a way to easily update > > packages in a way that recognizes from where installed packages were > > originally installed from after selectively install packages from a > > number of different vendors. I don't see a good solution to this > > problem since the rpmdb doesn't keep track of this sort of > > information. The closest thing that can be used to aid this sort of > > update is gpg signatures. > I agree, this is a different problem at all. But even then I would > reconsider. Assume package foo exiting at ATrpms at FC time, and > then it makes it into FC core. You wouldn't want to exclude the > upgrade path to another repo. Also some packages may be dropped by FC > like pine was, and it may reappear in another repo. Again, you'd like > to have upgrade paths not accidentially broken due to vendor/origin > lock mechanisms. > > I think these idioms are trying to cure something at the wrong > end. I'd ask the following: > > o What needs to be fixed? PEBCAK: Don't just "upgrade all" from external repositories, "upgrade the-package" only. If there are dependencies that must be satisfied from the external repo, it pulls them in; if not, nothing is changed. If standard packages are overwritten, well... Perhaps an easy way of telling yum to pull from a (disabled, or marked external in some other way and thus not considered by default) repository would solve most of the problem? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From ivg2 at cornell.edu Mon Jan 2 14:29:26 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 09:29:26 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <1136218074.2936.34.camel@laptopd505.fenrus.org> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> Message-ID: <43B938C6.6010003@cornell.edu> Arjan van de Ven wrote: >> Also, I still run kernel 1688, because I don't want to deal with the >> hassle of making the livna nvidia driver work with modular X for every >> new kernel. Which kernel started including this tracking patch >> > > oh you're using the binary nvidia driver; would maybe have been useful > to give info like that in the initial report ;) (eg what hardware is > involved, what kernel stuff what X stuff etc etc) > That was a mailing list question, I'll file a bug report if someone suggests the correct component. I don't see the point of writing lots of information until requested - it may or may not be relevant. Kernel is 1688, with the binary nvidia driver. Software is fedora rawhide + rawhide extras + livna + selinux repository, All non-obsolete or broken packages installed as of 2-3 days ago. The hardware is an Athlon 1600+, nvidia 5700 (256MB), 512MB SDRAM. This is a rather old computer, but that doesn't explain the behavior I am seeing. From vonbrand at inf.utfsm.cl Mon Jan 2 16:39:47 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 02 Jan 2006 13:39:47 -0300 Subject: FC5 and Yum Plugins In-Reply-To: Your message of "Fri, 30 Dec 2005 09:37:52 -0800." <1135964272.7671.18.camel@locolhost.localdomain> Message-ID: <200601021639.k02Gdl6o010524@laptop11.inf.utfsm.cl> Michael A. Peters wrote: > On Fri, 2005-12-30 at 09:09 -0500, Jeff Spaleta wrote: > > You are volunteering to help Axel out by responding to all the bug > > reports he's getting from people who are using priorities to filter > > out parts of atrpms? Seems only fair. Here you are delibrately > > encouraging people to use a method to subvert the structure of the 3rd > > party repository and creating an additional burden on the repo > > maintainers. > When I ran a repo - I had two. > One contained packages that did not conflict with core/extras > One contained packages that would conflict (replace) packages in > core/extras. And a third one contained versions of packages in the first one which required packages in the second one, but were fixed to work with the vanilla versions? If not, the whole excercise is futile... [...] > When someone has a bunch of stuff replaced from a third party > repository, are they still running Fedora Core or are they running a > hybrid? That's the problem I have with repositories that replace core > packages. They may have more features, but I don't know that they get > properly patched when vulnerabilities are found, etc. - so replacing a > core package is imho a bad idea unless you know you need to. Perhaps the system should be marked "tainted" when installing third-party packages, like the kernel is for binary modules... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From jspaleta at gmail.com Mon Jan 2 16:48:16 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 2 Jan 2006 11:48:16 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B938C6.6010003@cornell.edu> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> Message-ID: <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> On 1/2/06, Ivan Gyurdiev wrote: > Kernel is 1688, with the binary nvidia driver. Software is fedora > rawhide + rawhide extras + livna + selinux repository, All non-obsolete > or broken packages installed as of 2-3 days ago. The hardware is an > Athlon 1600+, nvidia 5700 (256MB), 512MB SDRAM. This is a rather old > computer, but that doesn't explain the behavior I am seeing. Several questions which you have the power to answer: Does similiar behavior occur when you revert back to the provided nv driver? if yes.... While using the nv driver, does similar behavior occure when you run the latest rawhide kernel. if yes.... While using the nv driver with the latest rawhide kernel, do you see this behavior after putting selinux in permissive mode? I have for example a rawhide system using a dual Athlon 1800MP GeForce FX 5200 and 512MB ram and the nv driver with selinux off and I do not notice what you describe occuring on my gnome desktop. There are certaintly funtastic issues with gnome at the moment (like the multiple gnome-terminal problem) on my system, but nothing as wide-spread as what you describe. If I were a betting man I'd bet that nvidia driver is the major problem here. If you can't reproduce this behavior using the nv driver and the latest rawhide packageset including the kernel, there isn't much fedora developers can help you with. -jef"looking forward to the day when nvidia releases beta drivers... because what could be more fun than running bleeding untested daily nvidia driver builds on bleeding untested daily rawhide builds..except maybe a triple root canal operation during a novacaine shortage"spaleta From vonbrand at inf.utfsm.cl Mon Jan 2 16:50:50 2006 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 02 Jan 2006 13:50:50 -0300 Subject: FC5 and Yum Plugins In-Reply-To: Message from Axel Thimm of "Sat, 31 Dec 2005 19:41:30 BST." <20051231184130.GB15058@neu.nirvana> Message-ID: <200601021650.k02GootD010640@laptop11.inf.utfsm.cl> Axel Thimm wrote: [...] > No, seriously. I guess you are a victim of this FUD just like many > other people, too. There really isn't any correlation between a > package being replaced/updated and having more bugs for this packages. Humm... I'd guess you update /because/ there are unfixed bugs in the vanilla version, so... ;-) OTOH, I was burned some time back the other way around: On my x86_64 the kernel wouldn't boot. So (on the suggestion of LKML) I went and tried a bisection search for the patch which broke the kernel... but it was Fedora optimizing the kernel for size, which Linus' configuration didn't do. Lots of wasted time there. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From jspaleta at gmail.com Mon Jan 2 17:24:49 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 2 Jan 2006 12:24:49 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <200601021639.k02Gdl6o010524@laptop11.inf.utfsm.cl> References: <1135964272.7671.18.camel@locolhost.localdomain> <200601021639.k02Gdl6o010524@laptop11.inf.utfsm.cl> Message-ID: <604aa7910601020924h34de1499m49e55b47ca3af44a@mail.gmail.com> On 1/2/06, Horst von Brand wrote: > Perhaps the system should be marked "tainted" when installing third-party > packages, like the kernel is for binary modules... Who benefits from marking a system as tainted when 3rd party packages are installed and how do they benefit? I understand how taint is used in the context of kernel modules.. I do not see how taint is useful from a packaging system persepective since the scope of the packaging system is so much wider when it comes to potential problems. Are we as a project going to say "sorry package system is tainted, closing bugreport as wontfix"? Are we going to taint someone's system because they are using a test version of Xorg subpackages from mharris's people.redhat.com at mharris's explicit request? Are we going to taint systems for using updates-testing? Or for using a few packages out of rawhide when testing to see if a bug is fixed? I just don't get how tainting a system because a few non-standard packages are installed helps anyone, especially since we have no child-safe way to "downgrade" back to standard packages after the system is tainted. If the problem is users are unware that certain repos overlap before they start using them and would prefer to use repos in a way that did not overlap Core. Then the solution is to provide approprate notification mechanism which makes users aware before they install packages from overlapping repos, not to taint their system after the fact. I would prefer instead per package notification when the to be updated package has a different signing key then the installed package and let the user decide as to whether or not to let the package update move forward. Can this sort of notification be added to yum's review list in a compact and easily digestable way.. i have no idea. I'm sure the sig comparison would slow yum down so I'm sure it would be an unpopular feature among segments of the userbase. This notification mechanism could be extended to cause a transaction failure for automated updates, similar to a missing dep failure and users can use scripts similar to the scripts in the wiki, which work around broken deps to do partial updates, to do partial updates which do not cross the signing key barrier and to log package updates that do cross the signing key barrier for later inspection. Once notified about package updates that change signing keys, users can choose to use exclude,includepkgs per repo in their configs to prevent that situation from happening in the future for those particular packages. -jef From dakingun at gmail.com Mon Jan 2 17:26:32 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Mon, 2 Jan 2006 12:26:32 -0500 Subject: Replacing LAM with OpenMPI in Fedora Core Message-ID: >From the frontpage of the lam's website (http://www.lam-mpi.org/); "LAM/MPI is now in a maintenance mode. Bug fixes and critical patches are still being applied, but little real "new" work is happening in LAM/MPI. This is a direct result of the LAM/MPI Team spending the vast majority of their time working on our next-generation MPI implementation -- Open MPI." The site also states that, "Since it's an MPI implementation, you should be able to simply recompile and re-link your applications to Open MPI -- they should "just work." Open MPI contains many features and performance enhancements that are not available in LAM/MPI." Thanks. Deji From ivg2 at cornell.edu Mon Jan 2 15:34:34 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 10:34:34 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> Message-ID: <43B9480A.5010305@cornell.edu> > Several questions which you have the power to answer: > Does similiar behavior occur when you revert back to the provided nv driver? > if yes.... > Yes. > While using the nv driver, does similar behavior occure when you run > the latest rawhide kernel. > if yes.... > Yes. > While using the nv driver with the latest rawhide kernel, do you see > this behavior after putting selinux in permissive mode? > I always selinux run in permissive mode. > I have for example a rawhide system using a > dual Athlon 1800MP GeForce FX 5200 and 512MB ram and the nv driver > with selinux off and I do not notice what you describe occuring on my > gnome desktop. There are certaintly funtastic issues with gnome at > the moment (like the multiple gnome-terminal problem) on my system, > Which problem is that? I have one where switching to consoles 1-6,8,9 makes the screen go pink with a garbled rectangle in one corner, instead of showing the login prompt - it's really fun, especially when X freezes on console 7. (and yes, this was with the nv driver). > -jef"looking forward to the day when nvidia releases beta drivers... > because what could be more fun than running bleeding untested daily > nvidia driver builds on bleeding untested daily rawhide builds..except > maybe a triple root canal operation during a novacaine > shortage"spaleta > Ivan"looking forward to when arjan/jeff stop blaming nvidia for every problem on the fedora desktop, and hell freezes over" G. P.S. The nv driver makes my LCD say: Out Of Range, and then hover strangely, and suspend itself after 30 sec. - makes me rather worried about my monitor, so I'm back to a stable nvidia driver that works (most of the time :) Wasn't kudzu in charge of updating frequency things in xorg.conf when I switch monitors? It doesn't seem to be doing its job - I had to manually disable 1600x1200 resolution for any picture to come up in the first place. From jspaleta at gmail.com Mon Jan 2 18:01:49 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 2 Jan 2006 13:01:49 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B9480A.5010305@cornell.edu> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> Message-ID: <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> On 1/2/06, Ivan Gyurdiev wrote: > > > Several questions which you have the power to answer: > > Does similiar behavior occur when you revert back to the provided nv driver? > > if yes.... > > > Yes. > > While using the nv driver, does similar behavior occure when you run > > the latest rawhide kernel. > > if yes.... > > > Yes. > > While using the nv driver with the latest rawhide kernel, do you see > > this behavior after putting selinux in permissive mode? > > > I always selinux run in permissive mode. Then I have to say i can't confirm what you see. I'm not seeing appreciable extended periods of high cpu utilization for my rawhide synced gnome desktop running the nv driver and selinux permissive mode with my normal application usage patterns. Or even when I try to produce it by randomly starting a variety of applications. You might be experiencing something triggered by a specific application that I'm not running. You never told us which process was actually cpu spiking in your posts so far. Is it the end-user applications, gnome infrastructure, X.. the kernel related processes? Are thereother interesting configurations in play mounted network filesystems? raid? >>There are certaintly funtastic issues with gnome at >> the moment (like the multiple gnome-terminal problem) on my system, > > Which problem is that? I have one where switching to consoles 1-6,8,9 > makes the screen go pink with a garbled rectangle in one corner, instead > of showing the login prompt - it's really fun, especially when X freezes > on console 7. (and yes, this was with the nv driver). I'm not seeing this behavior at all I can switch consoles all the live long day on my rawhide box. I was refering to the problem with gnome-terminal hanging which has been reported in either test-list and devel-list by several people in the last week or so... its a problem specific to gnome-terminal and has nothing to do with problems are are suggesting here which you are suggesting are rather application agnostic. > Ivan"looking forward to when arjan/jeff stop blaming nvidia for every > problem on the fedora desktop, and hell freezes over" G. Shrug, hopefully you can find someone who can confirm the problems you are experiencing. I don't see this going very far towards resolution without more specifics or some cross-referencing multiple affected systems. But you should know better by now. Reporting problems while running the nvidia driver aren't going to get much of any attention from fedora developers simply because they don't have access to the code. Put your best foot forward in the convesation and start the discussion based on a system running the nv driver. > P.S. The nv driver makes my LCD say: All of these tests have used the LCD moniter? I have a crt on my system. Do you need to enable the FlatPanel option for the nv driver? -jef From ivg2 at cornell.edu Mon Jan 2 16:18:32 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 11:18:32 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> Message-ID: <43B95258.8050208@cornell.edu> > > Then I have to say i can't confirm what you see. I'm not seeing > appreciable extended periods of high cpu utilization for my rawhide > synced gnome desktop running the nv driver and selinux permissive mode > with my normal application usage patterns. Or even when I try to > produce it by randomly starting a variety of applications. You might > be experiencing something triggered by a specific application that I'm > not running. You never told us which process was actually cpu spiking > in your posts so far. Gnumeric, gnome-terminal, firefox, rhythmbox, applets. > Is it the end-user applications, gnome > infrastructure, X.. the kernel related processes? Are thereother > interesting configurations in play mounted network filesystems? raid? > I have a mounted samba share, but I doubt that has anything to do with it. There's no raid. >>> There are certaintly funtastic issues with gnome at >>> the moment (like the multiple gnome-terminal problem) on my system, >>> >> Which problem is that? I have one where switching to consoles 1-6,8,9 >> makes the screen go pink with a garbled rectangle in one corner, instead >> of showing the login prompt - it's really fun, especially when X freezes >> on console 7. (and yes, this was with the nv driver). >> > > I'm not seeing this behavior at all I can switch consoles all the live > long day on my rawhide box. I was refering to the problem with > gnome-terminal hanging which has been reported in either test-list and > devel-list by several people in the last week or so... its a problem > specific to gnome-terminal and has nothing to do with problems are are > suggesting here which you are suggesting are rather application > agnostic. > Well, I haven't had any problems with the gnome-terminal hanging :) Really, most bugs are dependent on configuration issues to detect. I happen to have every Fedora package installed (with 90% of the services disabled, of course), so sometimes I get to see fun bugs that nobody else ever does. For example, did you know that libsafe (used to be in extras) will break prelink for every app? I found that out recently, and filed a bug, but now I see libsafe is gone from the repo (I did prelink successfully after that, so that's not the issue here). >> Ivan"looking forward to when arjan/jeff stop blaming nvidia for every >> problem on the fedora desktop, and hell freezes over" G. >> > > Shrug, hopefully you can find someone who can confirm the problems you > are experiencing. I don't see this going very far towards resolution > without more specifics or some cross-referencing multiple affected > systems. Right. I wouldn't normally consider slowness surprising, but it's the pattern that looks weird to me. My thinking is that some kind of core gnome library is doing something wrong. >> P.S. The nv driver makes my LCD say: >> > > All of these tests have used the LCD moniter? I have a crt on my > system. Do you need to enable the FlatPanel option for the nv driver? > I have no idea - I don't normally mess with xorg.conf at all (or use the nv driver). I would expect kudzu (or something) to do more work to detect what kind of monitor I have - at least get the frequency/resolutions right. From ed at eh3.com Mon Jan 2 18:25:00 2006 From: ed at eh3.com (Ed Hill) Date: Mon, 02 Jan 2006 13:25:00 -0500 Subject: Replacing LAM with OpenMPI in Fedora Core In-Reply-To: References: Message-ID: <1136226300.30006.345.camel@ernie> On Mon, 2006-01-02 at 12:26 -0500, Deji Akingunola wrote: > >From the frontpage of the lam's website (http://www.lam-mpi.org/); > "LAM/MPI is now in a maintenance mode. Bug fixes and critical patches > are still being applied, but little real "new" work is happening in > LAM/MPI. This is a direct result of the LAM/MPI Team spending the vast > majority of their time working on our next-generation MPI > implementation -- Open MPI." > The site also states that, "Since it's an MPI implementation, you > should be able to simply recompile and re-link your applications to > Open MPI -- they should "just work." Open MPI contains many features > and performance enhancements that are not available in LAM/MPI." Hi Deji and everyone else interested in MPI, I understand that OpenMPI is supposed to [at least, for some people's perception! ;-)] become the "one true MPI" implementation that eclipses all others due to its very cool new modular design and other features. But, even so, I think it would be a good idea to have and maintain other MPI versions (such as MPICH v1 & v2, LAM, etc.) in Extras so that people have some flexibility. And to do that, we'll very likely need to setup the multiple MPI packages using alternatives. The OpenMPI and MPICH2 packages that we (Deji and I) have submitted to FE: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173719 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171993 are not yet setup for alternates but that certainly can be done -- it probably wouldn't be too hard to add that capability. So, my questions are: 1) Who are the LAM maintainer(s) within Red Hat and can they *please* step forward and discuss the Fedora plans for MPI in general and LAM in particular? 2) If its possible, could we please modify LAM so that it can work with other MPI implementations through alternatives? 3) And could we perhaps move LAM out of Core? Or maybe substitute OpenMPI for LAM if one MPI must remain as the default in Core? I know that this will take some work but we've already made some progress and now its time for someone within Red Hat to speak up and work with us. Please! Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From ivg2 at cornell.edu Mon Jan 2 16:28:05 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 11:28:05 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B95258.8050208@cornell.edu> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B95258.8050208@cornell.edu> Message-ID: <43B95495.3050003@cornell.edu> > I have no idea - I don't normally mess with xorg.conf at all (or use > the nv driver). I would expect kudzu (or something) to do more work to > detect what kind of monitor I have - at least get the > frequency/resolutions right. I see no FlatPanel option - the options are the one that the nvidia driver uses, since the program that switches them doesn't change the options. Interesting things in xorg include: RENDER = yes, glx = on, dri = on I'm not sure why you're suspicious of the graphics driver, however... From smooge at gmail.com Mon Jan 2 18:40:16 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 2 Jan 2006 11:40:16 -0700 Subject: Royalty free gstreamer plug-in In-Reply-To: <6b9c17630601012336g662ba4eeoabea8a2ffaf0bf5b@mail.gmail.com> References: <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> <43B1393E.5070601@laPoste.net> <6b9c17630601012336g662ba4eeoabea8a2ffaf0bf5b@mail.gmail.com> Message-ID: <80d7e4090601021040g4bb652c5wa30eb99fa01360d1@mail.gmail.com> On 1/2/06, Jeff Pitman wrote: > On 12/27/05, Nicolas Mailhot wrote: > > Jeff Pitman a ?crit : > > > > > Let's not forget that the "holier-than-thou" stance alienates quite a few users. > > > > And the permissive attitude of some distributions alienate others. > > Fedora has to take one side on the IP rights debate. And no matter > > which one is it, people on the other side will be "alienated" by this > > choice. > > > > I don't think we need another Mandriva/Linspire in the Linux world. > > I was actually thinking more along the lines of Ubuntu. Universe is > commented out in sources.list and it is extremely well documented on > how to get MP3 activated. The same can be done here. > Actually no. I dont think Ubuntu is not formed inside of the United States, while both Red Hat and Fedora are considered to be "Entities within the United States" for the purpose of suing. In the US, a simple comment and then document how to violate can be construed as helping an illegal activity. While the US courts have been clear that writing about how to pick a lock is not illegal.. they have not been so clear with source code, depending on your Federal District it can be considered illegal or legal. I have no idea how Novell gets away with it.. it can be anything from existing contracts/patent transfers to waiting to be sued so they can fight that battle then. The issue though is that the standard suing game in patents and other infringement claims is to go after smaller players first and then go up the ladder with won cases as precedent. -- Stephen J Smoogen. CSIRT/Linux System Administrator From arjan at fenrus.demon.nl Mon Jan 2 18:53:40 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 02 Jan 2006 19:53:40 +0100 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B95495.3050003@cornell.edu> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B95258.8050208@cornell.edu> <43B95495.3050003@cornell.edu> Message-ID: <1136228021.2936.53.camel@laptopd505.fenrus.org> On Mon, 2006-01-02 at 11:28 -0500, Ivan Gyurdiev wrote: > > I have no idea - I don't normally mess with xorg.conf at all (or use > > the nv driver). I would expect kudzu (or something) to do more work to > > detect what kind of monitor I have - at least get the > > frequency/resolutions right. > > I see no FlatPanel option - the options are the one that the nvidia > driver uses, since the program that switches them doesn't change the > options. Interesting things in xorg include: RENDER = yes, glx = on, dri > = on > > I'm not sure why you're suspicious of the graphics driver, however... because it has a kernel component, and some things in the kernel got slower due to a few debug option... especially for places that do "dumb" things (see davej's blog for a few such places in the kernel source ;) The nv driver has no kernel portion, so wouldn't suffer from the same debugging.. From mitr at volny.cz Mon Jan 2 19:11:55 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 02 Jan 2006 20:11:55 +0100 Subject: "GUI gadgets", was: Fedora meeting Mono Half-Way In-Reply-To: <43B8F480.3020201@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <43A1A782.8000506@cornell.edu> <1134725344.11167.5.camel@wombat.tiptoe.de> <43A299E9.2080802@cornell.edu> <1134741282.2764.7.camel@wombat.tiptoe.de> <43B8F480.3020201@cornell.edu> Message-ID: <43B97AFB.7080602@volny.cz> Ivan Gyurdiev wrote: > My password files are not relevant - yes, the tomcat4 user has a > password in shadow, and no entry in passwd (probably I erased it > manually a long time ago). That is very likely relevant. > Yes, this is a configuration problem, but I > think the program should warn about it and skip that user, instead of > refusing to work altogether. Let me know if you still want a bugzilla. Bugzilla is always the right place to report a bug (as opposed to f-d-l). Please file a bug, you can Cc: mitr at redhat.com if you like. Thanks, Mirek From ivg2 at cornell.edu Mon Jan 2 17:22:03 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 12:22:03 -0500 Subject: "GUI gadgets", was: Fedora meeting Mono Half-Way In-Reply-To: <43B97AFB.7080602@volny.cz> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <43A1A782.8000506@cornell.edu> <1134725344.11167.5.camel@wombat.tiptoe.de> <43A299E9.2080802@cornell.edu> <1134741282.2764.7.camel@wombat.tiptoe.de> <43B8F480.3020201@cornell.edu> <43B97AFB.7080602@volny.cz> Message-ID: <43B9613B.9000008@cornell.edu> Miloslav Trmac wrote: > Ivan Gyurdiev wrote: > >> My password files are not relevant - yes, the tomcat4 user has a >> password in shadow, and no entry in passwd (probably I erased it >> manually a long time ago). >> > That is very likely relevant. > Yes, I understand this is what causes the bug. If I get rid of the tomcat4 user, it works. My point is that it shouldn't have this behavior - it should be more fault-tolerant. Will file bugzilla later today. From nicolas.mailhot at laposte.net Mon Jan 2 19:27:07 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 02 Jan 2006 20:27:07 +0100 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> Message-ID: <43B97E8B.3020309@laposte.net> Jeff Spaleta wrote: > Then I have to say i can't confirm what you see. I'm not seeing > appreciable extended periods of high cpu utilization for my rawhide > synced gnome desktop running the nv driver and selinux permissive mode > with my normal application usage patterns. Please do not dismiss this report - I've experienced the very same symptoms (nvidia-less and not tainted systems). Never reported them because could not find what was blocking and why. But the experience related there is very close to mine. I think the effects are worse on old slow systems, and under the human tolerance threshold on faster computers (thanksfully I'm back on my fast system now, rawhide on an Athlon 550 was disgusting last week) -- Nicolas Mailhot From pemboa at gmail.com Mon Jan 2 19:47:37 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 2 Jan 2006 13:47:37 -0600 Subject: edit root alias when installing the OS In-Reply-To: <1136198504.11175.101.camel@locolhost.localdomain> References: <1136149140.3230.5.camel@rivendell.home.local> <1136150058.3376.13.camel@tuxhugger> <1136198504.11175.101.camel@locolhost.localdomain> Message-ID: <16de708d0601021147k24a9005crd781fa0831eb2f39@mail.gmail.com> On 1/2/06, Michael A. Peters wrote: > > On Sun, 2006-01-01 at 13:14 -0800, Peter Gordon wrote: > > On Sun, 2006-01-01 at 12:59 -0800, Florin Andrei wrote: > > > Wouldn't make sense to edit /etc/aliases while installing the OS and > ask > > > the operator to provide a real email as an alias? > > > It is a very common error to forget the root alias. As a result, the > > > email sent by housekeeping software (such as logwatch) is ignored, > often > > > with unpleasant results. > > > > > > > https://www.redhat.com/archives/fedora-list/2006-January/thread.html#00045 > > > > > > This may or may not require to edit the relayhost variable in the MTA > > > (ask the operator to provide a default mail relay), I'm not sure > > > (depending on how "correct" or thorough the installer should be). > > > > That sounds like a good idea to me. Perhaps it could default to aliasing > > root to the user created during firstboot, or something similar? > > It should go to a local user and it should ask which local user. > root always should go to a local user, and if needed, the local user can > then forward to somewhere else - but it should go to a local user first > so that if there is a problem delivering, you don't end up with a loop > to the root account. > > Then it should also be made easy to have that users mailed copied/forwarded to another email -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivg2 at cornell.edu Mon Jan 2 18:55:24 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 13:55:24 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B97E8B.3020309@laposte.net> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B97E8B.3020309@laposte.net> Message-ID: <43B9771C.2080208@cornell.edu> >> Then I have to say i can't confirm what you see. I'm not seeing >> appreciable extended periods of high cpu utilization for my rawhide >> synced gnome desktop running the nv driver and selinux permissive mode >> with my normal application usage patterns. > > Please do not dismiss this report - I've experienced the very same > symptoms (nvidia-less and not tainted systems). Never reported them > because could not find what was blocking and why. But the experience > related there is very close to mine. > > I think the effects are worse on old slow systems, and under the human > tolerance threshold on faster computers (thanksfully I'm back on my > fast system now, rawhide on an Athlon 550 was disgusting last week) This is an important point - like I said, this is a slower computer, and it's not all that slow (I would say 18 seconds as opposed to 4 to start up gnumeric). Jeff, you have faster processors, and you have two of them, so maybe you don't see a problem. From jarod at wilsonet.com Mon Jan 2 21:37:57 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Mon, 2 Jan 2006 13:37:57 -0800 Subject: edit root alias when installing the OS In-Reply-To: <1136166695.2828.8.camel@rivendell.home.local> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> Message-ID: <200601021338.00925.jarod@wilsonet.com> On Sunday 01 January 2006 17:51, Florin Andrei wrote: > On Sun, 2006-01-01 at 14:51 -0800, Jarod Wilson wrote: > > Would probably have to be in firstrun, since there's no user accounts > > created within Anaconda anymore. A simple check box for "deliver system > > mail to this user" in firstboot that triggers the change ought to do the > > trick. That's pretty much what SUSE has been doing for a while now. > > Hmmm, but I don't think that too many people configure their MUAs to > slurp in the mailbox of that account. > Allowing the operator to enter an arbitrary email address to receive the > email from root might be more realistic. I think I'm with Michael Peters on this one, it should go to a local user first. The local account can then be set up w/a .forward/.procmailrc file or further aliases editing to send it on elsewhere, or the user can just look at their local mailbox. By default, even if you're not checking the local box, you get notified of new mail there in a shell, and allowing the user to send the mail to an external (and possibly not accessible due to any number of reasons) email address could indeed result in some nasty loops. -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Mon Jan 2 21:42:24 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 2 Jan 2006 16:42:24 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B9771C.2080208@cornell.edu> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B97E8B.3020309@laposte.net> <43B9771C.2080208@cornell.edu> Message-ID: <604aa7910601021342h5e646d5cif0687b33a9300606@mail.gmail.com> On 1/2/06, Ivan Gyurdiev wrote: > This is an important point - like I said, this is a slower computer, and > it's not all that slow (I would say 18 seconds as opposed to 4 to start > up gnumeric). Jeff, you have faster processors, and you have two of > them, so maybe you don't see a problem. yep.. your right... there is a huge jump in cpu technology between my athlon 1800mp cpus and your athlon 1600.... even when i boot the system into the uniprocessor kernel and attempt to recreate these symptoms without any success. Yes most definitely we are much more dissimiliar than the difference between your system and nicolas's reported athlon 550. Shrug, I hope you two pinpoint the problem. -jef From ivg2 at cornell.edu Mon Jan 2 20:57:01 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 15:57:01 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <604aa7910601021342h5e646d5cif0687b33a9300606@mail.gmail.com> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B97E8B.3020309@laposte.net> <43B9771C.2080208@cornell.edu> <604aa7910601021342h5e646d5cif0687b33a9300606@mail.gmail.com> Message-ID: <43B9939D.1010100@cornell.edu> > Shrug, I hope you two pinpoint the problem. > Of course we'll pinpoint the problem.. going to investigate right now. Nicolas, what apps are slow on your machine? Can you send me a copy of your xorg.conf off-list just in case (although I think this focus on the nvidia driver is going in the wrong direction), considering that this is *patterned* behavior of *GNOME* *GUI* applications, which everyone seems to ignore. It's probably some sort of gtk/cairo craziness that's making it slow. I can now confirm same behavior on giFT and BitTorrent file sharing tool (gtk2 apps). You know what the worst part is - the screensaver. I've been wondering for a while why I must endure the black screen with no response for like 20 seconds after I move the mouse, and this is most likely the answer. Now I just need to figure out why it happens. Something in the last few weeks of upgrades broke it. I haven't done upgrades for that time, since I was stuck at 128MB RAM and yum took forever to do anything at all...but, for the record, the screensaver worked properly. From ivg2 at cornell.edu Mon Jan 2 20:59:11 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 15:59:11 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <1136228021.2936.53.camel@laptopd505.fenrus.org> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B95258.8050208@cornell.edu> <43B95495.3050003@cornell.edu> <1136228021.2936.53.camel@laptopd505.fenrus.org> Message-ID: <43B9941F.9010504@cornell.edu> >>> I have no idea - I don't normally mess with xorg.conf at all (or use >>> the nv driver). I would expect kudzu (or something) to do more work to >>> detect what kind of monitor I have - at least get the >>> frequency/resolutions right. >>> >> I see no FlatPanel option - the options are the one that the nvidia >> driver uses, since the program that switches them doesn't change the >> options. Interesting things in xorg include: RENDER = yes, glx = on, dri >> = on >> >> I'm not sure why you're suspicious of the graphics driver, however... >> > > because it has a kernel component, and some things in the kernel got > slower due to a few debug option... especially for places that do "dumb" > things (see davej's blog for a few such places in the kernel source ;) > The nv driver has no kernel portion, so wouldn't suffer from the same > debugging.. > Can you clarify which kernel version enabled the debug option? From darrellpf at gmail.com Mon Jan 2 23:09:05 2006 From: darrellpf at gmail.com (darrell pfeifer) Date: Mon, 2 Jan 2006 15:09:05 -0800 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B9941F.9010504@cornell.edu> References: <43B92BBB.9050909@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B95258.8050208@cornell.edu> <43B95495.3050003@cornell.edu> <1136228021.2936.53.camel@laptopd505.fenrus.org> <43B9941F.9010504@cornell.edu> Message-ID: I have a two year old laptop that uses the radeon driver. The last few kernels from rawhide left a really sluggish response. Switching between virtual screens gave a really noticeable repaint. I also had the feeling that I/O in general was very slow. The latest 1806 kernel is much better, so this might not be an X problem. darrell From nicolas.mailhot at laposte.net Mon Jan 2 23:49:11 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 03 Jan 2006 00:49:11 +0100 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B9939D.1010100@cornell.edu> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B97E8B.3020309@laposte.net> <43B9771C.2080208@cornell.edu> <604aa7910601021342h5e646d5cif0687b33a9300606@mail.gmail.com> <43B9939D.1010100@cornell.edu> Message-ID: <43B9BBF7.6060904@laposte.net> Ivan Gyurdiev wrote: > >> Shrug, I hope you two pinpoint the problem. >> > Of course we'll pinpoint the problem.. going to investigate right now. > > Nicolas, what apps are slow on your machine? I don't have access to this system right now (thanksfully, it was driving me crazy). I do remember it was very frustrating, because sometime launching a new app / app instance was instantaneous, and other times the same launcher took 20 - 30 s to start doing stuff. The apps used were mainly gnome-term, thunderbird, firefox, rhythmbox > Can you send me a copy of > your xorg.conf off-list just in case (although I think this focus on the > nvidia driver is going in the wrong direction), Considering the athlon still uses a mach64 card (ATI Xpert at work) I doubt nvidia is the cuprit. rEGARDS,, -- Nicolas Mailhot From jarod at wilsonet.com Mon Jan 2 23:51:25 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Mon, 2 Jan 2006 15:51:25 -0800 Subject: edit root alias when installing the OS In-Reply-To: <1136167377.2938.0.camel@rivendell.home.local> References: <1136149140.3230.5.camel@rivendell.home.local> <43B887D5.3070505@redhat.com> <1136167377.2938.0.camel@rivendell.home.local> Message-ID: <200601021551.28691.jarod@wilsonet.com> On Sunday 01 January 2006 18:02, Florin Andrei wrote: > On Mon, 2006-01-02 at 07:24 +0530, Rahul Sundaram wrote: > > file a RFE in bugzilla against firstboot. > > done > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176767 And I just attached a quick patch to implement something along these lines, though it still needs some further love to do everything correctly (like postalias /etc/aliases if the user is running postfix, because postfix starts before firstboot, might need to do similar for sendmail, can't remember, I haven't used sendmail in ages). -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Mon Jan 2 23:53:25 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 03 Jan 2006 00:53:25 +0100 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: References: <43B92BBB.9050909@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B95258.8050208@cornell.edu> <43B95495.3050003@cornell.edu> <1136228021.2936.53.camel@laptopd505.fenrus.org> <43B9941F.9010504@cornell.edu> Message-ID: <43B9BCF5.80902@laposte.net> darrell pfeifer wrote: > I have a two year old laptop that uses the radeon driver. > > The last few kernels from rawhide left a really sluggish response. > Switching between virtual screens gave a really noticeable repaint. I > also had the feeling that I/O in general was very slow. > > The latest 1806 kernel is much better, so this might not be an X problem. My feeling was more some sort of scheduler problem, with apps being randomly starved. As long as you stayed in the same app everything was very fast, trying to switch or launch a new app would either be reasonably fast of slow as hell. Starvation was not linked to any particular app, more (like Ivan noted) to launch ordering. I never noticed any particular load peak that could explain the slowdowns. And this box had 256 MB which is not bad for its generation and the only reason it can still be used. -- Nicolas Mailhot From seg at haxxed.com Tue Jan 3 00:15:52 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 02 Jan 2006 18:15:52 -0600 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B9480A.5010305@cornell.edu> References: <43B92BBB.9050909@cornell.edu> <20060102153742.GA11754@ryoko.camperquake.de> <43B92FE8.2080702@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> Message-ID: <1136247353.17263.15.camel@hamburger.booze> On Mon, 2006-01-02 at 10:34 -0500, Ivan Gyurdiev wrote: > Which problem is that? I have one where switching to consoles 1-6,8,9 > makes the screen go pink with a garbled rectangle in one corner, instead > of showing the login prompt - it's really fun, especially when X freezes > on console 7. (and yes, this was with the nv driver). I noticed when I updated my system a few days ago, it now loads the rivafb module. And I know for a fact that rivafb and X do not get along, and haven't for years. Flipping between vconsoles, or even just restarting the X server, will lock the whole console hard after a few times. Yes, this is with the open source "nv" driver. And rivafb seems quite buggy anyway. Is your system loading rivafb? -------------- 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 ivg2 at cornell.edu Mon Jan 2 22:38:48 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 02 Jan 2006 17:38:48 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B9BCF5.80902@laposte.net> References: <43B92BBB.9050909@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B95258.8050208@cornell.edu> <43B95495.3050003@cornell.edu> <1136228021.2936.53.camel@laptopd505.fenrus.org> <43B9941F.9010504@cornell.edu> <43B9BCF5.80902@laposte.net> Message-ID: <43B9AB78.70906@cornell.edu> Nicolas Mailhot wrote: > darrell pfeifer wrote: >> I have a two year old laptop that uses the radeon driver. >> >> The last few kernels from rawhide left a really sluggish response. >> Switching between virtual screens gave a really noticeable repaint. I >> also had the feeling that I/O in general was very slow. >> >> The latest 1806 kernel is much better, so this might not be an X >> problem. > > My feeling was more some sort of scheduler problem, with apps being > randomly starved. As long as you stayed in the same app everything was > very fast, trying to switch or launch a new app would either be > reasonably fast of slow as hell. Starvation was not linked to any > particular app, more (like Ivan noted) to launch ordering. > > I never noticed any particular load peak that could explain the > slowdowns. And this box had 256 MB which is not bad for its generation > and the only reason it can still be used. But see...those are all GUI apps. More specifically, they're all gtk apps. Correct me if I'm wrong, but wouldn't a kernel issue affect all apps on the system - it doesn't appear that way to me. Also, I don't know if this is relevant, but if you compare `strace -c` on a fast and slow run, they look almost exactly the same syscall distribution, and cover a very small amount of total time (1 sec). I was particularly interested in bittorrent, as a simple test case - doesn't it only link to gtk2 over pygtk2? We know python isn't the issue, since C apps are slow too. However... this is interesting. I observe no slowdown as root - all the apps start reasonably fast. Can you confirm this? Also, I see that there have been no significant changes in gtk2 lately, while I know that this bug must have been caused by upgrades in the last two weeks or so. Hmmm... From seg at haxxed.com Tue Jan 3 00:56:11 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 02 Jan 2006 18:56:11 -0600 Subject: FC5 and Yum Plugins In-Reply-To: <20051231193432.GE15058@neu.nirvana> References: <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> <3adc77210512310757p3115c13buf10b3a6198c95c8b@mail.gmail.com> <604aa7910512310849t4217a176ne884326b12ec0d15@mail.gmail.com> <1136049422.3516.166.camel@pmac.infradead.org> <20051231183147.GA15058@neu.nirvana> <20051231193432.GE15058@neu.nirvana> Message-ID: <1136249772.17263.19.camel@hamburger.booze> On Sat, 2005-12-31 at 20:34 +0100, Axel Thimm wrote: > Oh yes, it did: > > https://www.redhat.com/archives/fedora-list/2005-January/msg01826.html > > Maybe it doesn't anymore, but for good manners everytime a yum release > comes up and mentiones bugs fixed I run and distribute it to ATrpms > folks and they are *happy* about it. Especially the ones running FC > older then the latest, that doesn't get any yum problems fixed > anymore. Wouldn't the right thing to do be to push to get stuff like this fixed in Fedora, rather than happily replacing a core package with your own at the slightest provocation? (And to Fedora developers, you should also be receptive to accepting bug fixes like this in a timely manner...) -------------- 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 wtogami at redhat.com Tue Jan 3 00:53:16 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 02 Jan 2006 19:53:16 -0500 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> Message-ID: <43B9CAFC.1010209@redhat.com> Jeff Pitman wrote: > On 1/2/06, Florin Andrei wrote: >> On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote: >> >>> When users choose to use third party repositories they are in many cases >>> not aware that they are not just adding packages but also replacing >>> existing ones in their system which might be a divergence they desire. >>> The discussions initiated by one such user along with various posting in >>> fedora forum, user lists and irc channel is enough proof that the >>> problem exists. > > (Offtopic: is anyone else's mail not picking up Rahul's list postings? > I've seen several responses to Rahul's email, however I haven't > received any from Rahul since 12/27 from fedora-devel. Odd...) > >> This is currently the single most important problem with package >> repositories. > > See Warren's posting: Core/Extras has no obligation to help the situation. Furthermore, I personally consider 3rd party repositories to be forks of the distribution. In most cases this is no problem if they do not overlap and do not replace Core/Extras packages. A "fork" is not necessarily a bad thing. Only users should be aware that they use such repositories at their own option, and if they have any problems they need to report it to their fork project/repository to deal with it. It is not Fedora's responsibility to workaround problems caused by forks or 3rd party software. Warren Togami wtogami at redhat.com From jarod at wilsonet.com Tue Jan 3 01:28:31 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Mon, 2 Jan 2006 17:28:31 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <43B9CAFC.1010209@redhat.com> References: <20051231195043.GF15058@neu.nirvana> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <43B9CAFC.1010209@redhat.com> Message-ID: <200601021728.34147.jarod@wilsonet.com> On Monday 02 January 2006 16:53, Warren Togami wrote: > Jeff Pitman wrote: > > On 1/2/06, Florin Andrei wrote: > >> On Mon, 2006-01-02 at 05:24 +0530, Rahul Sundaram wrote: > >>> When users choose to use third party repositories they are in many > >>> cases not aware that they are not just adding packages but also > >>> replacing existing ones in their system which might be a divergence > >>> they desire. The discussions initiated by one such user along with > >>> various posting in fedora forum, user lists and irc channel is enough > >>> proof that the problem exists. > > > > (Offtopic: is anyone else's mail not picking up Rahul's list postings? > > I've seen several responses to Rahul's email, however I haven't > > received any from Rahul since 12/27 from fedora-devel. Odd...) > > > >> This is currently the single most important problem with package > >> repositories. > > > > See Warren's posting: Core/Extras has no obligation to help the > > situation. > > Furthermore, I personally consider 3rd party repositories to be forks of > the distribution. In most cases this is no problem if they do not > overlap and do not replace Core/Extras packages. > > A "fork" is not necessarily a bad thing. Only users should be aware > that they use such repositories at their own option, and if they have > any problems they need to report it to their fork project/repository to > deal with it. It is not Fedora's responsibility to workaround problems > caused by forks or 3rd party software. While I agree that it isn't necessarily Fedora's responsibility to play nice with 3rd-party repositories, I think it ought to be a goal to make using 3rd-party repositories as painless as possible. I think there are quite a few people who might not use Fedora, if not for the 3rd-party repositories. If there's a fix or functionality addition to a core package needed for another package maintained by a 3rd-party, why not push them into the core versions? Then people who want software out of the 3rd-party repo but don't want core packages replaced get to have their cake and eat it too, and 3rd-party repositories don't get bashed as much. Everybody wins, no? Of course, someone within Red Hat would probably have to step up as 3rd-party repository liaison to coordinate the effort... But I think its something worth doing, for the sake of the Fedora community at large. -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Tue Jan 3 02:12:22 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 02 Jan 2006 21:12:22 -0500 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <200601021728.34147.jarod@wilsonet.com> References: <20051231195043.GF15058@neu.nirvana> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <43B9CAFC.1010209@redhat.com> <200601021728.34147.jarod@wilsonet.com> Message-ID: <43B9DD86.5060507@redhat.com> Jarod Wilson wrote: > On Monday 02 January 2006 16:53, Warren Togami wrote: >> Furthermore, I personally consider 3rd party repositories to be forks of >> the distribution. In most cases this is no problem if they do not >> overlap and do not replace Core/Extras packages. >> >> A "fork" is not necessarily a bad thing. Only users should be aware >> that they use such repositories at their own option, and if they have >> any problems they need to report it to their fork project/repository to >> deal with it. It is not Fedora's responsibility to workaround problems >> caused by forks or 3rd party software. > > While I agree that it isn't necessarily Fedora's responsibility to play nice > with 3rd-party repositories, I think it ought to be a goal to make using > 3rd-party repositories as painless as possible. I think there are quite a few > people who might not use Fedora, if not for the 3rd-party repositories. > > If there's a fix or functionality addition to a core package needed for > another package maintained by a 3rd-party, why not push them into the core > versions? Then people who want software out of the 3rd-party repo but don't > want core packages replaced get to have their cake and eat it too, and > 3rd-party repositories don't get bashed as much. Everybody wins, no? > > Of course, someone within Red Hat would probably have to step up as 3rd-party > repository liaison to coordinate the effort... But I think its something > worth doing, for the sake of the Fedora community at large. > It is an anti-goal of Fedora to promote the proliferation of arbitrary mixes of 3rd party repositories as the standard way of using Fedora. A central goal of Fedora is collaborative development in a centralized repository. For this reason it is untenable to expect or suggest Red Hat to explicitly coordinate with 3rd party repositories. Your post is also problematic in completely ignoring potential legal implications of an official relationship between Fedora and 3rd party repositories. Users have an option of using 3rd party software, but the responsible party for dealing with problems shifts in such cases. If you have concerns about individual packages, please file bugs in Red Hat Bugzilla. Changes can be made to individual Core/Extras packages are usually general bug fixes and enhancements. It is wrong to expect Fedora to make special concessions only to work around problems introduced by 3rd parties. If it is the right thing to do in general cases, then it is proper to make changes to Core/Extras. Warren Togami wtogami at redhat.com From jeff.pitman at gmail.com Tue Jan 3 02:23:12 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Tue, 3 Jan 2006 10:23:12 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <200601021728.34147.jarod@wilsonet.com> References: <20051231195043.GF15058@neu.nirvana> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <43B9CAFC.1010209@redhat.com> <200601021728.34147.jarod@wilsonet.com> Message-ID: <6b9c17630601021823j67504138w7bbd3c6e8e4bd630@mail.gmail.com> On 1/3/06, Jarod Wilson wrote: > If there's a fix or functionality addition to a core package needed for > another package maintained by a 3rd-party, why not push them into the core > versions? Then people who want software out of the 3rd-party repo but don't > want core packages replaced get to have their cake and eat it too, and > 3rd-party repositories don't get bashed as much. Everybody wins, no? I think what Warren is saying is that this channel already exists: in the form of Bugzilla. It would be at the discretion of each package maintainer to fold any improvements or patches into Core. So, there really doesn't need to be any explicit effort to bridge the two. For example, I have submitted issues that were fixed in Core based on work that I was doing on my repo. This is due to the fact that my repo replaces Python well before Core does and so I can see some potential problems a priori Core integration. But, that's not to say it doesn't get frustrating. I mean: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130352 That bug is a good example. It's a PITA. And, it will never get fixed. The implicit obsoletes kills a lot of attempts to stay away from Core packages. I tried to not touch the python package, but, I threw up my arms after trying for along time. So, you win some and you lose some. Setting up a meta project to bridge 3rd party to Core will just be unnecessary because the same politics and technical issues will still exist. -- -jeff From wtogami at redhat.com Tue Jan 3 02:32:16 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 02 Jan 2006 21:32:16 -0500 Subject: Multiple installed python In-Reply-To: <6b9c17630601021823j67504138w7bbd3c6e8e4bd630@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <43B9CAFC.1010209@redhat.com> <200601021728.34147.jarod@wilsonet.com> <6b9c17630601021823j67504138w7bbd3c6e8e4bd630@mail.gmail.com> Message-ID: <43B9E230.4000701@redhat.com> Jeff Pitman wrote: > > But, that's not to say it doesn't get frustrating. I mean: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130352 > > That bug is a good example. It's a PITA. And, it will never get fixed. > The implicit obsoletes kills a lot of attempts to stay away from Core > packages. I tried to not touch the python package, but, I threw up my > arms after trying for along time. So, you win some and you lose some. > rpm is the wrong component for this bug because it is behaving as designed. Why have you not asked the general python maintainers at Red Hat like misa, katzj or pjones instead? Maybe you have... but I see no comments from them in this ticket. Communication problem? Warren Togami wtogami at redhat.com From jeff.pitman at gmail.com Tue Jan 3 02:43:20 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Tue, 3 Jan 2006 10:43:20 +0800 Subject: Multiple installed python In-Reply-To: <43B9E230.4000701@redhat.com> References: <20051231195043.GF15058@neu.nirvana> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <43B9CAFC.1010209@redhat.com> <200601021728.34147.jarod@wilsonet.com> <6b9c17630601021823j67504138w7bbd3c6e8e4bd630@mail.gmail.com> <43B9E230.4000701@redhat.com> Message-ID: <6b9c17630601021843g3a610020y7180372e2f689f7@mail.gmail.com> On 1/3/06, Warren Togami wrote: > rpm is the wrong component for this bug because it is behaving as > designed. Why have you not asked the general python maintainers at Red > Hat like misa, katzj or pjones instead? Maybe you have... but I see no > comments from them in this ticket. I resolved this by replacing the core package so I have python15, python22, python23, python24; instead of having "python" as the core package. Otherwise, an upgrade of python will implicitly Obsoletes the other packages because they Provide a virtual python. I actually ran through the scenarios, at length, with several individuals inside and outside of Redhat about 1.5+ years ago. This seemed to be the best resolution at the time since the aforementioned bug is "As Designed". I'm mainly using this as an example about the occasional hiccups when dealing with Core and 3rd party repos rather than rattling old bones. -- -jeff From jeff.pitman at gmail.com Tue Jan 3 04:14:07 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Tue, 3 Jan 2006 12:14:07 +0800 Subject: Mirrors list needs to be livened up. In-Reply-To: <43B6C6DA.5010801@redhat.com> References: <43B6C50D.4060307@interplas.com> <43B6C6DA.5010801@redhat.com> Message-ID: <6b9c17630601022014q251e7bfcn97dfcf5ba2319abe@mail.gmail.com> On 1/1/06, Rahul Sundaram wrote: > See http://fedoraproject.org/wiki/Infrastructure/MirrorManagement. Your > ideas could probably add value to that. I think we've had this discussion before, but I think it's important that Mirrors utilize the --delay-updates option to rsync to minimize problems with packages and metadata out of sync. Resource requirements from man page: """This option uses more memory on the receiving side (one bit per file transferred) and also requires enough free disk space on the receiving side to hold an additional copy of all the updated files. """ Obviously, to initialize the mirror, you don't want this option. However, upon incremental syncs, I believe it to be wholly beneficial to the end user as it will reduce the number of bad mirrors. Can someone with access to the wiki mention this information for mirrors? I can, if you want: username "JeffPitman". -- -jeff From jarod at wilsonet.com Tue Jan 3 04:18:02 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Mon, 2 Jan 2006 20:18:02 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <43B9DD86.5060507@redhat.com> References: <20051231195043.GF15058@neu.nirvana> <200601021728.34147.jarod@wilsonet.com> <43B9DD86.5060507@redhat.com> Message-ID: <200601022018.02960.jarod@wilsonet.com> On Monday 02 January 2006 18:12, Warren Togami wrote: > Jarod Wilson wrote: > > While I agree that it isn't necessarily Fedora's responsibility to play > > nice with 3rd-party repositories, I think it ought to be a goal to make > > using 3rd-party repositories as painless as possible. I think there are > > quite a few people who might not use Fedora, if not for the 3rd-party > > repositories. > > > > If there's a fix or functionality addition to a core package needed for > > another package maintained by a 3rd-party, why not push them into the > > core versions? Then people who want software out of the 3rd-party repo > > but don't want core packages replaced get to have their cake and eat it > > too, and 3rd-party repositories don't get bashed as much. Everybody wins, > > no? > > > > Of course, someone within Red Hat would probably have to step up as > > 3rd-party repository liaison to coordinate the effort... But I think its > > something worth doing, for the sake of the Fedora community at large. > > It is an anti-goal of Fedora to promote the proliferation of arbitrary > mixes of 3rd party repositories as the standard way of using Fedora. A > central goal of Fedora is collaborative development in a centralized > repository. I'm not saying Fedora should promote arbitrary mixes of 3rd-party repositories, just that there aren't really any good reasons not to cooperate with them, at least on some level. If repository X needs an updated libfoo to build application bar that tons of users want, why not update Core's libfoo? I suppose bugzilla is the place to log such requests right now, but many don't get addressed in a very timely fashion, leading to 3rd-party replacement packages and/or simply no longer bothering to log such request. > For this reason it is untenable to expect or suggest Red > Hat to explicitly coordinate with 3rd party repositories. Perhaps my use of "coordinate" wasn't the best. Strike "coordinate the effort" and replace with "maintain an open and active, bi-directional line of communication". There are several large 3rd-party repositories with a wealth of experience, so why not leverage them more? Fedora itself is definitely in the driver's seat, but why ignore directions from 3rd-party repositories, simply because they're 3rd-party? > Your post is > also problematic in completely ignoring potential legal implications of > an official relationship between Fedora and 3rd party repositories. Okay, so don't make it an official relationship. (Can anyone say "livna"?). Of course, IANAL, but I don't see any legal problem with fixing or updating core libs/packages that are already in the distro, so long as it isn't adding mp3 support or the like. > Users have an option of using 3rd party software, but the responsible > party for dealing with problems shifts in such cases. > > If you have concerns about individual packages, please file bugs in Red > Hat Bugzilla. Changes can be made to individual Core/Extras packages > are usually general bug fixes and enhancements. It is wrong to expect > Fedora to make special concessions only to work around problems > introduced by 3rd parties. If it is the right thing to do in general > cases, then it is proper to make changes to Core/Extras. I'm not talking so much about problems introduced by 3rd-parties as I am about problems/deficiencies uncovered by 3rd-parties, i.e., fixing packages in Core in a timely fashion to eliminate the need of 3rd-party packagers to replace Core components. -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff.pitman at gmail.com Tue Jan 3 05:33:23 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Tue, 3 Jan 2006 13:33:23 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <200601022018.02960.jarod@wilsonet.com> References: <20051231195043.GF15058@neu.nirvana> <200601021728.34147.jarod@wilsonet.com> <43B9DD86.5060507@redhat.com> <200601022018.02960.jarod@wilsonet.com> Message-ID: <6b9c17630601022133q3e7d3265r9918515cc01b89fb@mail.gmail.com> On 1/3/06, Jarod Wilson wrote: > On Monday 02 January 2006 18:12, Warren Togami wrote: > > If you have concerns about individual packages, please file bugs in Red > > Hat Bugzilla. Changes can be made to individual Core/Extras packages > > are usually general bug fixes and enhancements. It is wrong to expect > > Fedora to make special concessions only to work around problems > > introduced by 3rd parties. If it is the right thing to do in general > > cases, then it is proper to make changes to Core/Extras. > > I'm not talking so much about problems introduced by 3rd-parties as I am about > problems/deficiencies uncovered by 3rd-parties, i.e., fixing packages in Core > in a timely fashion to eliminate the need of 3rd-party packagers to replace > Core components. Also, it's good to have allies on the inside. See jpackage FAQ about "I tried to install foo on Fedora Core 2, but got lots of error messages and/or things don't work": http://www.jpackage.org/faq.php Note the line: """This issue should be fixed in Fedora Core 3, thanks to Red Hat's involvement in JPackage.""" Google cache from one of the messages since the archive is broke: http://66.102.7.104/search?q=cache:I2Me1f05Eb0J:lists.zarb.org/pipermail/jpackage-discuss/2004-October/011253.html+jpackage-discuss++011253&hl=en&client=firefox-a Sound familiar? And, in about 6 months "Core/Extras vs 3rd Party" might show up on this list again... -- -jeff From jarod at wilsonet.com Tue Jan 3 05:53:35 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Mon, 2 Jan 2006 21:53:35 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <6b9c17630601022133q3e7d3265r9918515cc01b89fb@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <200601022018.02960.jarod@wilsonet.com> <6b9c17630601022133q3e7d3265r9918515cc01b89fb@mail.gmail.com> Message-ID: <200601022153.38790.jarod@wilsonet.com> On Monday 02 January 2006 21:33, Jeff Pitman wrote: > On 1/3/06, Jarod Wilson wrote: > > On Monday 02 January 2006 18:12, Warren Togami wrote: > > > If you have concerns about individual packages, please file bugs in Red > > > Hat Bugzilla. Changes can be made to individual Core/Extras packages > > > are usually general bug fixes and enhancements. It is wrong to expect > > > Fedora to make special concessions only to work around problems > > > introduced by 3rd parties. If it is the right thing to do in general > > > cases, then it is proper to make changes to Core/Extras. > > > > I'm not talking so much about problems introduced by 3rd-parties as I am > > about problems/deficiencies uncovered by 3rd-parties, i.e., fixing > > packages in Core in a timely fashion to eliminate the need of 3rd-party > > packagers to replace Core components. > > Also, it's good to have allies on the inside. Very true. Most 3rd-party repos don't, apparently. > See jpackage FAQ about > "I tried to install foo on Fedora Core 2, but got lots of error > messages and/or things don't work": http://www.jpackage.org/faq.php > > Note the line: > > """This issue should be fixed in Fedora Core 3, thanks to Red Hat's > involvement in JPackage.""" So the anti-3rd-party repository stance isn't unilaterally applied against all 3rd-party repos, I take it? > Google cache from one of the messages since the archive is broke: > http://66.102.7.104/search?q=cache:I2Me1f05Eb0J:lists.zarb.org/pipermail/jp >ackage-discuss/2004-October/011253.html+jpackage-discuss++011253&hl=en&clien >t=firefox-a > > Sound familiar? And, in about 6 months "Core/Extras vs 3rd Party" > might show up on this list again... Yeah, most likely. But hey, if JPackage can get Red Hat's help, I don't see why other repositories can't... -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff.pitman at gmail.com Tue Jan 3 06:03:24 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Tue, 3 Jan 2006 14:03:24 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <200601022153.38790.jarod@wilsonet.com> References: <20051231195043.GF15058@neu.nirvana> <200601022018.02960.jarod@wilsonet.com> <6b9c17630601022133q3e7d3265r9918515cc01b89fb@mail.gmail.com> <200601022153.38790.jarod@wilsonet.com> Message-ID: <6b9c17630601022203q541bb69fo21ccbfc502cd4e07@mail.gmail.com> On 1/3/06, Jarod Wilson wrote: > On Monday 02 January 2006 21:33, Jeff Pitman wrote: > > On 1/3/06, Jarod Wilson wrote: > > Note the line: > > > > """This issue should be fixed in Fedora Core 3, thanks to Red Hat's > > involvement in JPackage.""" > > So the anti-3rd-party repository stance isn't unilaterally applied against all > 3rd-party repos, I take it? Right, generally, if you package for livna or jpackage, you're sitting pretty good. There's a lot of history behind this along with different packagers being in the right place at the right time. Basically, a specific repo has a social status and requires high merit points to get things moving in a direction that they need. It's a bit like us as individuals ... based on meritocracy and getting an inside scoop. Besides social engineering, there is no other formal mechanism to push forward smooth operation between Core/Extras and a third party. If users are not privy to the fact that Core packages have to be updated sometimes, then they can either fork or not use. It's a pretty simplistic view of things, but, it's the truth. -- -jeff From mpeters at mac.com Tue Jan 3 06:12:42 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 02 Jan 2006 22:12:42 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <200601022018.02960.jarod@wilsonet.com> References: <20051231195043.GF15058@neu.nirvana> <200601021728.34147.jarod@wilsonet.com> <43B9DD86.5060507@redhat.com> <200601022018.02960.jarod@wilsonet.com> Message-ID: <1136268763.17625.3.camel@locolhost.localdomain> On Mon, 2006-01-02 at 20:18 -0800, Jarod Wilson wrote: > On Monday 02 January 2006 18:12, Warren Togami wrote: > > I'm not saying Fedora should promote arbitrary mixes of 3rd-party > repositories, just that there aren't really any good reasons not to cooperate > with them, at least on some level. If repository X needs an updated libfoo to > build application bar that tons of users want, why not update Core's libfoo? One needs to be extremely cautious about updating a library in a live distro. I know it happens sometimes in Extras - but that is wrong too imho (unless they provide a compat package for the old version as well). From jeff.pitman at gmail.com Tue Jan 3 06:22:34 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Tue, 3 Jan 2006 14:22:34 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136268763.17625.3.camel@locolhost.localdomain> References: <20051231195043.GF15058@neu.nirvana> <200601021728.34147.jarod@wilsonet.com> <43B9DD86.5060507@redhat.com> <200601022018.02960.jarod@wilsonet.com> <1136268763.17625.3.camel@locolhost.localdomain> Message-ID: <6b9c17630601022222v62c236fdsb753c99d331d01a5@mail.gmail.com> On 1/3/06, Michael A. Peters wrote: > On Mon, 2006-01-02 at 20:18 -0800, Jarod Wilson wrote: > > On Monday 02 January 2006 18:12, Warren Togami wrote: > > > > > I'm not saying Fedora should promote arbitrary mixes of 3rd-party > > repositories, just that there aren't really any good reasons not to cooperate > > with them, at least on some level. If repository X needs an updated libfoo to > > build application bar that tons of users want, why not update Core's libfoo? > > One needs to be extremely cautious about updating a library in a live > distro. I know it happens sometimes in Extras - but that is wrong too > imho (unless they provide a compat package for the old version as well). > I doubt I am going to end the thread, but I hope to. There are two sets of users: 1) users that do not want Core updated, and 2) users that *do* want Core updated. Continuing to debate about why turns into a "emacs vs vi" debate. Seriously. Fedora should be agnostic as to either of these groups in any obvious, active endeavor. Of course, micro-steps need to be made on a per-package basis as reported via Bugzilla--when the maintainer finds it as an acceptable change. Otherwise, we work around them. And a final comment to the those users in #1: do not use repos that cater to #2. That's it. -- -jeff From mpeters at mac.com Tue Jan 3 06:34:13 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 02 Jan 2006 22:34:13 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <6b9c17630601022222v62c236fdsb753c99d331d01a5@mail.gmail.com> References: <20051231195043.GF15058@neu.nirvana> <200601021728.34147.jarod@wilsonet.com> <43B9DD86.5060507@redhat.com> <200601022018.02960.jarod@wilsonet.com> <1136268763.17625.3.camel@locolhost.localdomain> <6b9c17630601022222v62c236fdsb753c99d331d01a5@mail.gmail.com> Message-ID: <1136270054.17625.5.camel@locolhost.localdomain> On Tue, 2006-01-03 at 14:22 +0800, Jeff Pitman wrote: > > I doubt I am going to end the thread, but I hope to. > > There are two sets of users: 1) users that do not want Core updated, > and 2) users that *do* want Core updated. > > Continuing to debate about why turns into a "emacs vs vi" debate. which is a completely silly debate because everyone knows emacs is better. ;) From jeff.pitman at gmail.com Tue Jan 3 06:54:24 2006 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Tue, 3 Jan 2006 14:54:24 +0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <1136270054.17625.5.camel@locolhost.localdomain> References: <20051231195043.GF15058@neu.nirvana> <200601021728.34147.jarod@wilsonet.com> <43B9DD86.5060507@redhat.com> <200601022018.02960.jarod@wilsonet.com> <1136268763.17625.3.camel@locolhost.localdomain> <6b9c17630601022222v62c236fdsb753c99d331d01a5@mail.gmail.com> <1136270054.17625.5.camel@locolhost.localdomain> Message-ID: <6b9c17630601022254t557ac50bwdb049e81f00b3aab@mail.gmail.com> On 1/3/06, Michael A. Peters wrote: > On Tue, 2006-01-03 at 14:22 +0800, Jeff Pitman wrote: > > > > > I doubt I am going to end the thread, but I hope to. > > > > There are two sets of users: 1) users that do not want Core updated, > > and 2) users that *do* want Core updated. > > > > Continuing to debate about why turns into a "emacs vs vi" debate. > > which is a completely silly debate because everyone knows emacs is > better. ;) > Ok fine, what about, "Would we have won WWII if the otherside had nuclear weapons?" debate. -- -jeff From buildsys at redhat.com Tue Jan 3 08:13:09 2006 From: buildsys at redhat.com (Build System) Date: Tue, 3 Jan 2006 03:13:09 -0500 Subject: rawhide report: 20060103 changes Message-ID: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> Updated Packages: bash-3.1-1 ---------- * Mon Jan 02 2006 Tim Waugh 3.1-1 - 3.1. - No longer need ia64, utf8, multibyteifs, jobs, sigpipe, read-e-segfault, manpage, crash, pwd, afs, subshell patches. - Remove wrap patch for now. - Use upstream patch to fix arrays. binutils-2.16.91.0.5-1 ---------------------- * Mon Jan 02 2006 Jakub Jelinek 2.16.91.0.5-1 - update to 2.16.91.0.5 - don't error about .toc1 references to discarded sectiosn on ppc64 (#175944) coreutils-5.93-6 ---------------- * Mon Jan 02 2006 Dan Walsh 5.93-6 - Remove pam_selinux.so from su.pamd, not needed for targeted and Strict/MLS will have to newrole before using. dictd-1.9.15-5 -------------- * Mon Jan 02 2006 Karsten Hopp 1.9.15-5 - add BuildRequires libtool-ltdl-devel (#176505) epiphany-1.9.4-1 ---------------- * Mon Jan 02 2006 Christopher Aillon 1.9.4-1 - Update to 1.9.4 ethereal-0.10.14-2 ------------------ * Mon Jan 02 2006 Radek Vokal 0.10.14-2 - rebuilt against new net-snmp-5.3 - gtk dialog bug (#156568) * Thu Dec 29 2005 Radek Vokal 0.10.14-1 - update to 0.10.14 gimp-2:2.2.10-1 --------------- * Thu Dec 29 2005 Nils Philippsen - 2.2.10 - version 2.2.10 glibc-2.3.90-25 --------------- * Mon Jan 02 2006 Jakub Jelinek 2.3.90-25 - update from CVS - s390{,x} and sparc{,64} pointer mangling fixes - install a sanitized LinuxThreads * Mon Jan 02 2006 Jakub Jelinek 2.3.90-24 - update from CVS - nscd audit changes (#174422) - ppc{32,64} vDSO support and ppc32 hp-timing * Tue Dec 27 2005 Jakub Jelinek 2.3.90-23 - update from CVS - robust mutexes - fix transliteration segfaults (#176573, #176583) - ignore prelink temporaries in ldconfig (#176570) hplip-0.9.7-6 ------------- * Mon Jan 02 2006 Tim Waugh 0.9.7-6 - Rebuild. kernel-2.6.14-1.1808_FC5 ------------------------ * Mon Jan 02 2006 David Woodhouse - Merge experimental Broadcom wireless driver kudzu-1.2.17-1 -------------- * Sun Jan 01 2006 Bill Nottingham - 1.2.17-1 - handle pcilib string returns (#176490, #176724) libsemanage-1.5.3-3 ------------------- * Tue Dec 27 2005 Dan Walsh 1.5.3-3 - Add Ivans patch to turn on ports libsepol-1.11.1-2 ----------------- * Tue Dec 27 2005 Dan Walsh 1.11.1-2 - Add Ivans patch to make ports work libsetrans-0.1.13-1 ------------------- * Mon Jan 02 2006 Dan Walsh 0.1.13-1 - Apply some of Uli fixes and Russell patch to improve performance * Thu Dec 29 2005 Dan Walsh 0.1.12-1 - Add handling of ranges s0:c1-s0:c255 - Add handling of contiguous categories s0:c1.c5 - Also translate as much content as library can, and return untranslated when - library can not. Old library would not translate any categories if one - failed to translate. libxklavier-2.1-2 ----------------- * Tue Dec 27 2005 Christopher Aillon 2.1-2 - Pull in latest version and get rid of the annoying XKB error dialog m2crypto-0.15-3 --------------- * Tue Jan 03 2006 Miloslav Trmac - 0.15-3 - Add BuildRequires: swig mc-1:4.6.1a-6 ------------- * Wed Dec 28 2005 Jindrich Novy 4.6.1a-6 - display free space on a device assigned to current directory in main panels - correctly diplay characters in mcview for non-UTF-8 LANG set (#174007) thanks to Dmitry Butskoy mlocate-0.12-1 -------------- * Sat Dec 31 2005 Miloslav Trmac - 0.12-1 - Update to mlocate-0.12 net-snmp-5.3-1 -------------- * Fri Dec 30 2005 Radek Vokal - upgrade to 5.3 net-tools-1.60-58 ----------------- * Mon Jan 02 2006 Radek Vokal 1.60-58 - clear static buffers in interface.c by (#176714) netpbm-10.31-1 -------------- * Fri Dec 30 2005 Jindrich Novy 10.31-1 - update to 10.31 - update security patch - regenerate man pages php-5.1.1-7 ----------- * Mon Jan 02 2006 Joe Orton 5.1.1-7 - rebuild for new net-snmp policycoreutils-1.29.2-10 ------------------------- * Mon Jan 02 2006 Dan Walsh 1.29.2-10 - Fix restorecon to not say it is changing user section when -vv is specified * Tue Dec 27 2005 Dan Walsh 1.29.2-9 - Fixes for semanage, patch from Ivan and added a test script selinux-policy-2.1.6-22 ----------------------- * Mon Jan 02 2006 Dan Walsh 2.1.6-22 - Fix dovecot to allow dovecot_auth to look at /tmp * Mon Jan 02 2006 Dan Walsh 2.1.6-21 - Allow restorecon to read unlabeled_t directories in order to fix labeling. * Fri Dec 30 2005 Dan Walsh 2.1.6-20 - Add Logwatch policy squid-7:2.5.STABLE12-4 ---------------------- * Wed Dec 28 2005 Martin Stransky 7:2.5.STABLE12-4 - added follow-xff patch (#176055) - samba path fix (#176659) tetex-3.0-13 ------------ * Thu Dec 29 2005 Jindrich Novy 3.0-13 - update package descriptions - don't use obsolete bindings in texdoc vim-1:6.4.006-1 --------------- * Mon Jan 02 2006 Karsten Hopp 6.4.006-1 - patchlevel 6, fixes bz# 175048 * Tue Dec 20 2005 Karsten Hopp 6.4.004-2 - disable templates when editing new .c / .h files (#175878) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5smp OpenIPMI - 1.4.14-14.1.i386 requires libnetsnmp.so.9 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5smp jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 kdeutils - 6:3.5.0-2.i386 requires libnetsnmp.so.9 nut - 2.0.2-5.1.i386 requires libnetsnmp.so.9 openhpi - 2.2.1-1.i386 requires libnetsnmp.so.9 php-snmp - 5.1.1-7.i386 requires libnetsnmp.so.9 Broken deps for ia64 ---------------------------------------------------------- OpenIPMI - 1.4.14-14.1.ia64 requires libnetsnmp.so.9()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) kdeutils - 6:3.5.0-2.ia64 requires libnetsnmp.so.9()(64bit) nut - 2.0.2-5.1.ia64 requires libnetsnmp.so.9()(64bit) php-snmp - 5.1.1-7.ia64 requires libnetsnmp.so.9()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- OpenIPMI - 1.4.14-14.1.ppc requires libnetsnmp.so.9 cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 kdeutils - 6:3.5.0-2.ppc requires libnetsnmp.so.9 nut - 2.0.2-5.1.ppc requires libnetsnmp.so.9 openhpi - 2.2.1-1.ppc requires libnetsnmp.so.9 php-snmp - 5.1.1-7.ppc requires libnetsnmp.so.9 Broken deps for ppc64 ---------------------------------------------------------- OpenIPMI - 1.4.14-14.1.ppc64 requires libnetsnmp.so.9()(64bit) cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) kdeutils - 6:3.5.0-2.ppc64 requires libnetsnmp.so.9()(64bit) nut - 2.0.2-5.1.ppc64 requires libnetsnmp.so.9()(64bit) openhpi - 2.2.1-1.ppc64 requires libnetsnmp.so.9()(64bit) php-snmp - 5.1.1-7.ppc64 requires libnetsnmp.so.9()(64bit) Broken deps for s390 ---------------------------------------------------------- OpenIPMI - 1.4.14-14.1.s390 requires libnetsnmp.so.9 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 kdeutils - 6:3.5.0-2.s390 requires libnetsnmp.so.9 openhpi - 2.2.1-1.s390 requires libnetsnmp.so.9 php-snmp - 5.1.1-7.s390 requires libnetsnmp.so.9 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- OpenIPMI - 1.4.14-14.1.s390x requires libnetsnmp.so.9()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) kdeutils - 6:3.5.0-2.s390x requires libnetsnmp.so.9()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) openhpi - 2.2.1-1.s390x requires libnetsnmp.so.9()(64bit) php-snmp - 5.1.1-7.s390x requires libnetsnmp.so.9()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 OpenIPMI - 1.4.14-14.1.x86_64 requires libnetsnmp.so.9()(64bit) cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) kdeutils - 6:3.5.0-2.x86_64 requires libnetsnmp.so.9()(64bit) nut - 2.0.2-5.1.x86_64 requires libnetsnmp.so.9()(64bit) openhpi - 2.2.1-1.x86_64 requires libnetsnmp.so.9()(64bit) php-snmp - 5.1.1-7.x86_64 requires libnetsnmp.so.9()(64bit) From kwade at redhat.com Tue Jan 3 08:31:42 2006 From: kwade at redhat.com (Karsten Wade) Date: Tue, 03 Jan 2006 00:31:42 -0800 Subject: release notes beats translation freeze for FC5 test2 Message-ID: <1136277102.21442.109.camel@erato.phig.org> To create a content freeze for translation for FC5 test2, we are taking a snapshot of Docs/Beats to convert into XML. The milestone was Midnight UTC 02 January, which has passed. We'll be converting the content over the next twelve hours. Expect the snapshot from the Wiki to be in CVS by around 17:00 UTC 03 January. The Wiki remains open for changes. New content goes into the Web-only latest relnotes that are posted at the time of the test release. If you think you have a content change that needs to make it into the ISO: 1. Contact your beat writer[1], or 2. Make the content change to the Wiki[2] Then come to #fedora-docs or send email to to draw our attention to the change. [1] http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Beats#assignments [2] http://fedoraproject.org/wiki/Docs/Beats -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- 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 arjan at fenrus.demon.nl Tue Jan 3 08:58:10 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 03 Jan 2006 09:58:10 +0100 Subject: rawhide report: 20060103 changes In-Reply-To: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> Message-ID: <1136278691.2942.5.camel@laptopd505.fenrus.org> On Tue, 2006-01-03 at 03:13 -0500, Build System wrote: > kernel-2.6.14-1.1808_FC5 > ------------------------ > * Mon Jan 02 2006 David Woodhouse > - Merge experimental Broadcom wireless driver I thought the fedora kernel policy was "upstream first" .... I think there's about a dozen other drivers that warrant the same treatment as this broadcom one... at least 4 of which are wireless drivers as well for which the hardware is quite popular. From nphilipp at redhat.com Tue Jan 3 09:00:52 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 03 Jan 2006 10:00:52 +0100 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <20060102111055.GA6671@orient.maison.moi> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <1136184276.2981.66.camel@rivendell.home.local> <20060102111055.GA6671@orient.maison.moi> Message-ID: <1136278852.7347.23.camel@gibraltar.stuttgart.redhat.com> On Mon, 2006-01-02 at 12:10 +0100, Emmanuel Seyman wrote: > On Sun, Jan 01, 2006 at 10:44:36PM -0800, Florin Andrei wrote: > > > > Right, so repository XYZ carries the package ABC, which I need, but > > since XYZ fosters the repo hell, I shall simply walk away whistling. > > The correct thing to do would be to: > > 1) Complain to the repo maintainer that replacing Core (and Extras?) > packages is a big no-no. > 2) Find out why said repo maintainer feels the need to replace said > packages > 3) Submit a bug in Bugzilla to solve repo maintainer's need > 4) Wait for bug to be resolved. Wait for repo maintainer to rebuild > packages that don't conflict with Core/Extras anymore. 4a) Wait for bug to be CLOSED/WONTFIX because maintainer's needs would e.g. mean possibly violating patents. Unless everything has plug-ins or some other witty scheme to handle that comes up, we will likely see people rebuilding core packages with stuff enabled that we don't. 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 From paul at all-the-johnsons.co.uk Tue Jan 3 09:14:59 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 03 Jan 2006 09:14:59 +0000 Subject: rawhide report: 20060103 changes In-Reply-To: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> Message-ID: <1136279700.4919.31.camel@T7.Linux> Hi, > jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) > jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) Given these have been broken since before Christmas... > kdeutils - 6:3.5.0-2.x86_64 requires libnetsnmp.so.9()(64bit) > nut - 2.0.2-5.1.x86_64 requires libnetsnmp.so.9()(64bit) > openhpi - 2.2.1-1.x86_64 requires libnetsnmp.so.9()(64bit) > php-snmp - 5.1.1-7.x86_64 requires libnetsnmp.so.9()(64bit) and netsnmp seems somewhat needed, is there anyway to tweak the buildsystem so these dependencies are automatically rebuilt (even if upstream bits haven't been merged) to remove this circular dependency problem? TTFN Paul -- main(t,_,a) char*a;{return!0 References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> <20051231233759.GD1197025@hiwaay.net> <6b9c17630512312157xeab36fexa97e6007733df740@mail.gmail.com> <43B86BCE.6020302@redhat.com> <1136181344.2981.54.camel@rivendell.home.local> <6b9c17630601012210j2e94af9fu864f32925be6f502@mail.gmail.com> <1136184276.2981.66.camel@rivendell.home.local> <20060102111055.GA6671@orient.maison.moi> <1136278852.7347.23.camel@gibraltar.stuttgart.redhat.com> Message-ID: <40305.192.54.193.37.1136279658.squirrel@rousalka.dyndns.org> On Mar 3 janvier 2006 10:00, Nils Philippsen wrote: > On Mon, 2006-01-02 at 12:10 +0100, Emmanuel Seyman wrote: > 4a) Wait for bug to be CLOSED/WONTFIX because maintainer's needs would > e.g. mean possibly violating patents. > > Unless everything has plug-ins or some other witty scheme to handle that > comes up, we will likely see people rebuilding core packages with stuff > enabled that we don't. Now that gstreamer got working mp3/mpeg2/dvd pluggins in livna, a lot of the video-related forks could be solved by just using totem or another gstreamer-based app as video player. Seems this is the only video stack right now that got clean pluggin separation, enabling free/non-free repo separation without overlaps. Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Jan 3 09:17:25 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 3 Jan 2006 10:17:25 +0100 (CET) Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B9AB78.70906@cornell.edu> References: <43B92BBB.9050909@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B95258.8050208@cornell.edu> <43B95495.3050003@cornell.edu> <1136228021.2936.53.camel@laptopd505.fenrus.org> <43B9941F.9010504@cornell.edu> <43B9BCF5.80902@laposte.net> <43B9AB78.70906@cornell.edu> Message-ID: <53582.192.54.193.37.1136279845.squirrel@rousalka.dyndns.org> On Lun 2 janvier 2006 23:38, Ivan Gyurdiev wrote: > Nicolas Mailhot wrote: >> darrell pfeifer wrote: >>> I have a two year old laptop that uses the radeon driver. >>> >>> The last few kernels from rawhide left a really sluggish response. >>> Switching between virtual screens gave a really noticeable repaint. I >>> also had the feeling that I/O in general was very slow. >>> >>> The latest 1806 kernel is much better, so this might not be an X >>> problem. >> >> My feeling was more some sort of scheduler problem, with apps being >> randomly starved. As long as you stayed in the same app everything was >> very fast, trying to switch or launch a new app would either be >> reasonably fast of slow as hell. Starvation was not linked to any >> particular app, more (like Ivan noted) to launch ordering. >> >> I never noticed any particular load peak that could explain the >> slowdowns. And this box had 256 MB which is not bad for its generation >> and the only reason it can still be used. > But see...those are all GUI apps. Yep CLI is not affected. > More specifically, they're all gtk apps. > Correct me if I'm wrong, but wouldn't a kernel issue affect all apps on > the system - it doesn't appear that way to me. Also, I don't know if > this is relevant, but if you compare `strace -c` on a fast and slow run, > they look almost exactly the same syscall distribution, and cover a very > small amount of total time (1 sec). > > I was particularly interested in bittorrent, as a simple test case - > doesn't it only link to gtk2 over pygtk2? We know python isn't the > issue, since C apps are slow too. > > However... this is interesting. I observe no slowdown as root - all the > apps start reasonably fast. Can you confirm this? Not before quite a long time - won't even touch the slow system for a few months. Regards, -- Nicolas Mailhot From zaitcev at redhat.com Tue Jan 3 10:54:59 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 3 Jan 2006 02:54:59 -0800 Subject: rawhide report: 20060103 changes In-Reply-To: <1136278691.2942.5.camel@laptopd505.fenrus.org> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> <1136278691.2942.5.camel@laptopd505.fenrus.org> Message-ID: <20060103025459.6e7642c3.zaitcev@redhat.com> On Tue, 03 Jan 2006 09:58:10 +0100, Arjan van de Ven wrote: > On Tue, 2006-01-03 at 03:13 -0500, Build System wrote: > > > kernel-2.6.14-1.1808_FC5 > > ------------------------ > > * Mon Jan 02 2006 David Woodhouse > > - Merge experimental Broadcom wireless driver > I thought the fedora kernel policy was "upstream first" .... > I think there's about a dozen other drivers that warrant the same > treatment as this broadcom one... at least 4 of which are wireless > drivers as well for which the hardware is quite popular. You are just sore because you bought wrong card, right? :-) Seriously, let us remember why the Upstream First policy exists. It is there in order to prevent us from carrying drivers forever, beholden to requests of users, unable to discard them least deafening cries of "regression" raise to heavens. This means that it may be permissible to have drivers which we expect to be in the mainline soon. For example, Fedora (Rawhide) has libusual enabled. To date, it's the only distro which does so, to the best of my knowledge (unless we count Gentoo, where users can enable it if they install -mm). In the same way, Fedora ships patches for ub, which are not in mainline ... yet. The Broadcom is considered a shoe-in for upstream because it uses the softmac. And who else does? I am tempted to call you on your rhetoric of 4 other drivers. Show them to me, I'm curious. Well? As far as I am aware, you're just blowing smoke. Right this time, I am porting the driver for prism54 based USB adapters from Madwifi to softmac. If that works, I'll ask it to be included into mainline. There may even be a brief period when it may appear in Fedora while not in mainline (though not necesserily: depends on the amount of testing it gets in -mm or elsewhere). Naturally, if you are prescient and know that Devicescape will win, then I'd love to hear it. Otherwise, I just do not see where the other 4 may come from. -- Pete From arjan at fenrus.demon.nl Tue Jan 3 11:06:59 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 03 Jan 2006 12:06:59 +0100 Subject: rawhide report: 20060103 changes In-Reply-To: <20060103025459.6e7642c3.zaitcev@redhat.com> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> <1136278691.2942.5.camel@laptopd505.fenrus.org> <20060103025459.6e7642c3.zaitcev@redhat.com> Message-ID: <1136286419.2942.28.camel@laptopd505.fenrus.org> > > The Broadcom is considered a shoe-in for upstream because it uses > the softmac. And who else does? most other wireless is now using, or is moving to using the bscape layer instead. Sure bscape needs a bit of work to layer on top of the existing ieee80211 layer (like softmac does), but for me it sure isn't clear softmac will win in the end. Heck even the broadcom driver is ported to bscape too! From d.jacobfeuerborn at conversis.de Tue Jan 3 12:46:17 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Tue, 03 Jan 2006 13:46:17 +0100 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: References: <43B92BBB.9050909@cornell.edu> <1136218074.2936.34.camel@laptopd505.fenrus.org> <43B938C6.6010003@cornell.edu> <604aa7910601020848r63406d42h9ae77731a6ebb84c@mail.gmail.com> <43B9480A.5010305@cornell.edu> <604aa7910601021001s612bdbebib3bb238d2331403a@mail.gmail.com> <43B95258.8050208@cornell.edu> <43B95495.3050003@cornell.edu> <1136228021.2936.53.camel@laptopd505.fenrus.org> <43B9941F.9010504@cornell.edu> Message-ID: <43BA7219.1000704@conversis.de> darrell pfeifer wrote: > I have a two year old laptop that uses the radeon driver. > > The last few kernels from rawhide left a really sluggish response. > Switching between virtual screens gave a really noticeable repaint. I > also had the feeling that I/O in general was very slow. > > The latest 1806 kernel is much better, so this might not be an X problem. All of this *might* to a problem I reported on the xorg mailinglist last month. I also noticed quite sluggish performance so I ran oprofile and noticed that xorg calls fbcopyareammx quite a lot which results in two things: a) "sluggish"-looking drawing performance because of the cpu is used where the on-board blitter should be and b) spikes in cpu utilization because of a). Alan Coopersmith apparently found some problem with xorgs memory allocation which seems to push all pixmaps into host memory instead of the on-card memory which causes at least the radeon driver to hit a lot of cpu fallbacks and people with a fast cpu will obviously will see less of an impact. Eric Anholt is doing some memory manager work right now which hopefully fixes that issue. Regards, Dennis From alan at redhat.com Tue Jan 3 13:36:20 2006 From: alan at redhat.com (Alan Cox) Date: Tue, 3 Jan 2006 08:36:20 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <6b9c17630512270617k70a986c0y4d960547674aa9a@mail.gmail.com> References: <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> <43B113D2.4040102@redhat.com> <6b9c17630512270554p341011bepbce668c3f844be9b@mail.gmail.com> <43B149D9.9070907@redhat.com> <6b9c17630512270617k70a986c0y4d960547674aa9a@mail.gmail.com> Message-ID: <20060103133620.GD6751@devserv.devel.redhat.com> On Tue, Dec 27, 2005 at 10:17:05PM +0800, Jeff Pitman wrote: > least provide explicit instructions on how to get MP3 bootstrapped so > as to attract and retain new users. Instead of some vague FAQ in the The USSA does not permit free speech of that nature. See the 2600 case about decss. Even providing the URL to such subversive anti-large american company information is considered an offence. Alan From alan at redhat.com Tue Jan 3 13:59:37 2006 From: alan at redhat.com (Alan Cox) Date: Tue, 3 Jan 2006 08:59:37 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135348548.15650.41.camel@thomas.amantes> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> Message-ID: <20060103135937.GF6751@devserv.devel.redhat.com> On Fri, Dec 23, 2005 at 03:35:48PM +0100, Thomas Vander Stichele wrote: > Red Hat can sign a redistribution contract with Fluendo that allows them > to also rebuild this source code into binaries to which Fluendo's patent > license applies. Why should Red Hat treat Fluendo differently to other third party non-free package providers for Fedora ? Obviously the truely free bits of Fluendo are one thing, the non-free bits appear to be a private matter between Fluendo as an ISV and their customers who may or may not elect to use Fedora and want a Fluendo maintained yum repository From streeter at redhat.com Tue Jan 3 15:41:32 2006 From: streeter at redhat.com (Guy Streeter) Date: Tue, 03 Jan 2006 09:41:32 -0600 Subject: Palm sync status? In-Reply-To: <1135673524.18919.51.camel@speedy.iagorubio.net> References: <1135413325.3721.2.camel@rivendell.home.local> <1135432018.5814.14.camel@localhost.localdomain> <20051224165546.7fab755f.zaitcev@redhat.com> <1135629890.18919.28.camel@speedy.iagorubio.net> <20051226215132.35443831@nausicaa.camperquake.de> <1135673524.18919.51.camel@speedy.iagorubio.net> Message-ID: <1136302892.3325.3.camel@mentos.hsv.redhat.com> On Tue, 2005-12-27 at 09:52 +0100, Iago Rubio wrote: > On Mon, 2005-12-26 at 21:51 +0100, Ralf Ertzinger wrote: > > Hi. > > > > Iago Rubio wrote: > > > > > I've also seen KERNEL="ttyUSB[13579]" all around on the net, so it seems > > > the odd device - among the two created - is the one used to communicate > > > with the pilot. > > > > > > The Z22 always picks the ttyUSB1 device. > > > > That depends on how many USB/serial adapters you have inserted into the > > system at that time. > > Yes, I know :) > > I meant it always picks the ttyUSB1 among ttyUSB0 and ttyUSB1, so it > always picks the odd device. You can get more specific, to help it pick the right device. I have these lines in for my Sony Clie: BUS="usb", SYSFS{product}="Palm Handheld*", KERNEL="ttyUSB*", SYMLINK="pilot" BUS="usb", SYSFS{idVendor}="054c", SYSFS{idProduct}="0144", NAME="clie% n" Sorry if that ends up line-wrapped; it should only be two lines. I found the information about the product and id values using hal-device-manager (from the hal-gnome package). --Guy From jkeating at j2solutions.net Tue Jan 3 16:46:39 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 03 Jan 2006 08:46:39 -0800 Subject: rawhide report: 20060103 changes In-Reply-To: <1136279700.4919.31.camel@T7.Linux> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> <1136279700.4919.31.camel@T7.Linux> Message-ID: <1136306799.17395.4.camel@yoda.loki.me> On Tue, 2006-01-03 at 09:14 +0000, Paul F. Johnson wrote: > > jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) > > jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) > > Given these have been broken since before Christmas... These still need upstream attention to be able to build with the new gcj. > > kdeutils - 6:3.5.0-2.x86_64 requires libnetsnmp.so.9()(64bit) > > nut - 2.0.2-5.1.x86_64 requires libnetsnmp.so.9()(64bit) > > openhpi - 2.2.1-1.x86_64 requires libnetsnmp.so.9()(64bit) > > php-snmp - 5.1.1-7.x86_64 requires libnetsnmp.so.9()(64bit) > > and netsnmp seems somewhat needed, is there anyway to tweak the > buildsystem so these dependencies are automatically rebuilt (even if > upstream bits haven't been merged) to remove this circular dependency > problem? I'm not quite sure what you're question is. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 ivazquez at ivazquez.net Tue Jan 3 16:47:09 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 03 Jan 2006 11:47:09 -0500 Subject: rawhide report: 20060103 changes In-Reply-To: <1136306799.17395.4.camel@yoda.loki.me> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> <1136279700.4919.31.camel@T7.Linux> <1136306799.17395.4.camel@yoda.loki.me> Message-ID: <1136306829.30392.19.camel@ignacio.lan> On Tue, 2006-01-03 at 08:46 -0800, Jesse Keating wrote: > On Tue, 2006-01-03 at 09:14 +0000, Paul F. Johnson wrote: > > > kdeutils - 6:3.5.0-2.x86_64 requires libnetsnmp.so.9()(64bit) > > > nut - 2.0.2-5.1.x86_64 requires libnetsnmp.so.9()(64bit) > > > openhpi - 2.2.1-1.x86_64 requires libnetsnmp.so.9()(64bit) > > > php-snmp - 5.1.1-7.x86_64 requires libnetsnmp.so.9()(64bit) > > > > and netsnmp seems somewhat needed, is there anyway to tweak the > > buildsystem so these dependencies are automatically rebuilt (even if > > upstream bits haven't been merged) to remove this circular dependency > > problem? > > I'm not quite sure what you're question is. Is it possible to schedule automatic rebuilds of packages that are dependent on packages that have have non-backwards-compatible (e.g., SONAME change) changes? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 jkeating at j2solutions.net Tue Jan 3 17:10:17 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 03 Jan 2006 09:10:17 -0800 Subject: rawhide report: 20060103 changes In-Reply-To: <1136306829.30392.19.camel@ignacio.lan> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> <1136279700.4919.31.camel@T7.Linux> <1136306799.17395.4.camel@yoda.loki.me> <1136306829.30392.19.camel@ignacio.lan> Message-ID: <1136308217.17395.7.camel@yoda.loki.me> On Tue, 2006-01-03 at 11:47 -0500, Ignacio Vazquez-Abrams wrote: > > Is it possible to schedule automatic rebuilds of packages that are > dependent on packages that have have non-backwards-compatible (e.g., > SONAME change) changes? Theoretically I suppose. Automated rebuilding isn't always the answer. When things change like this, it gives the maintainer the opportunity to look upstream for source changes or at bugzilla for package bugs to fix when bumping to meet the new library version. The broken dep in rawhide is a great way of drawing attention to a particular package. Automated rebuilding would only draw this attention if the build fails in someway. We just have to put up with the fact that rawhide is broken from time to time. Especially around the holidays when the vacation schedules are not all in sync. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 tburke at redhat.com Tue Jan 3 17:39:19 2006 From: tburke at redhat.com (Tim Burke) Date: Tue, 03 Jan 2006 12:39:19 -0500 Subject: Fedora general improvements input survey invitation In-Reply-To: <437D3B1D.7050007@redhat.com> References: <437D3B1D.7050007@redhat.com> Message-ID: <43BAB6C7.4000509@redhat.com> Tim Burke wrote: > The Fedora Core team invites you to participate in a survey to help > identify the major ways in which Fedora can be improved for the > benefit of the community. The survey consists of 10 questions > involving Fedora Core and Fedora Extras. We are greatly interested in > your views and hope you can share your thoughts with us. > Thanks in advance for helping us to make Fedora better for all > involved. Upon conclusion of the survey, a summary of the results > will be shared. > > Hi Everyone, I hope you all had a great holiday. Sorry for the delay, and a sincere thanks to all who participated in the survey. The results of this survey are hung off the fedoraproject.org marketing page under a feedback section. http://fedoraproject.org/wiki/Marketing/Fedora From smooge at gmail.com Tue Jan 3 17:59:41 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 3 Jan 2006 10:59:41 -0700 Subject: Fedora general improvements input survey invitation In-Reply-To: <43BAB6C7.4000509@redhat.com> References: <437D3B1D.7050007@redhat.com> <43BAB6C7.4000509@redhat.com> Message-ID: <80d7e4090601030959n122a023eqac8ef91af50dd920@mail.gmail.com> On 1/3/06, Tim Burke wrote: > Tim Burke wrote: > > > The Fedora Core team invites you to participate in a survey to help > > identify the major ways in which Fedora can be improved for the > > benefit of the community. The survey consists of 10 questions > > involving Fedora Core and Fedora Extras. We are greatly interested in > > your views and hope you can share your thoughts with us. > > > > > Thanks in advance for helping us to make Fedora better for all > > involved. Upon conclusion of the survey, a summary of the results > > will be shared. > > > > > Hi Everyone, > > I hope you all had a great holiday. Sorry for the delay, and a sincere > thanks to all who participated in the survey. The results of this > survey are hung off the fedoraproject.org marketing page under a > feedback section. That would be http://fedoraproject.org/wiki/Marketing/Fedora for those who get lost in the wiki. > > http://fedoraproject.org/wiki/Marketing/Fedora > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- Stephen J Smoogen. CSIRT/Linux System Administrator From caillon at redhat.com Tue Jan 3 18:05:02 2006 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 03 Jan 2006 13:05:02 -0500 Subject: rawhide report: 20060103 changes In-Reply-To: <1136308217.17395.7.camel@yoda.loki.me> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> <1136279700.4919.31.camel@T7.Linux> <1136306799.17395.4.camel@yoda.loki.me> <1136306829.30392.19.camel@ignacio.lan> <1136308217.17395.7.camel@yoda.loki.me> Message-ID: <43BABCCE.5040207@redhat.com> On 01/03/2006 12:10 PM, Jesse Keating wrote: > On Tue, 2006-01-03 at 11:47 -0500, Ignacio Vazquez-Abrams wrote: > >> Is it possible to schedule automatic rebuilds of packages that are >> dependent on packages that have have non-backwards-compatible (e.g., >> SONAME change) changes? >> > > We just have to put up with the fact that rawhide is broken from time to > time. Especially around the holidays when the vacation schedules are > not all in sync. Or just look into the issue and fix it. Give the holiday gift of hacking. ;-) From jkeating at j2solutions.net Tue Jan 3 18:11:32 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 03 Jan 2006 10:11:32 -0800 Subject: rawhide report: 20060103 changes In-Reply-To: <43BABCCE.5040207@redhat.com> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> <1136279700.4919.31.camel@T7.Linux> <1136306799.17395.4.camel@yoda.loki.me> <1136306829.30392.19.camel@ignacio.lan> <1136308217.17395.7.camel@yoda.loki.me> <43BABCCE.5040207@redhat.com> Message-ID: <1136311892.28706.0.camel@yoda.loki.me> On Tue, 2006-01-03 at 13:05 -0500, Christopher Aillon wrote: > Or just look into the issue and fix it. Give the holiday gift of > hacking. ;-) What issue are you referring to? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 prarit at sgi.com Tue Jan 3 19:00:51 2006 From: prarit at sgi.com (Prarit Bhargava) Date: Tue, 3 Jan 2006 14:00:51 -0500 Subject: [PATCH] Fix sn_flush_device_kernel & spinlock initialization Message-ID: <20060103190021.14555.21393.sendpatchset@prarit.boston.redhat.com> This patch fixes BZ 176827. This patch separates the sn_flush_device_list struct into kernel and common (both kernel and PROM accessible) structures. As it was, if the size of a spinlock_t changed (due to additional CONFIG options, etc.) the sal call which populated the sn_flush_device_list structs would erroneously write data (and cause memory corruption and/or a panic). This patch does the following: 1. Removes sn_flush_device_list and adds sn_flush_device_common and sn_flush_device_kernel. 2. Adds a new SAL call to populate a sn_flush_device_common struct per device, not per widget as previously done. 3. Correctly initializes each device's sn_flush_device_kernel spinlock_t struct (before it was only doing each widget's first device). diff -urNp fedora-orig/arch/ia64/sn/include/xtalk/hubdev.h fedora-work/arch/ia64/sn/include/xtalk/hubdev.h --- fedora-orig/arch/ia64/sn/include/xtalk/hubdev.h 2006-01-03 10:36:41.000000000 -0500 +++ fedora-work/arch/ia64/sn/include/xtalk/hubdev.h 2006-01-03 10:37:21.000000000 -0500 @@ -26,11 +26,14 @@ #define IIO_NUM_ITTES 7 #define HUB_NUM_BIG_WINDOW (IIO_NUM_ITTES - 1) -struct sn_flush_device_list { +/* This struct is shared between the PROM and the kernel. + * Changes to this struct will require corresponding changes to the kernel. + */ +struct sn_flush_device_common { int sfdl_bus; int sfdl_slot; int sfdl_pin; - struct bar_list { + struct common_bar_list { unsigned long start; unsigned long end; } sfdl_bar_list[6]; @@ -40,14 +43,19 @@ struct sn_flush_device_list { uint32_t sfdl_persistent_busnum; uint32_t sfdl_persistent_segment; struct pcibus_info *sfdl_pcibus_info; +}; + +/* This struct is kernel only and is not used by the PROM */ +struct sn_flush_device_kernel { spinlock_t sfdl_flush_lock; + struct sn_flush_device_common *common; }; /* - * **widget_p - Used as an array[wid_num][device] of sn_flush_device_list. + * **widget_p - Used as an array[wid_num][device] of sn_flush_device_kernel. */ struct sn_flush_nasid_entry { - struct sn_flush_device_list **widget_p; /* Used as a array of wid_num */ + struct sn_flush_device_kernel **widget_p; // Used as an array of wid_num uint64_t iio_itte[8]; }; diff -urNp fedora-orig/arch/ia64/sn/kernel/io_init.c fedora-work/arch/ia64/sn/kernel/io_init.c --- fedora-orig/arch/ia64/sn/kernel/io_init.c 2006-01-03 10:36:41.000000000 -0500 +++ fedora-work/arch/ia64/sn/kernel/io_init.c 2006-01-03 10:37:21.000000000 -0500 @@ -76,11 +76,12 @@ static struct sn_pcibus_provider sn_pci_ }; /* - * Retrieve the DMA Flush List given nasid. This list is needed - * to implement the WAR - Flush DMA data on PIO Reads. + * Retrieve the DMA Flush List given nasid, widget, and device. + * This list is needed to implement the WAR - Flush DMA data on PIO Reads. */ -static inline uint64_t -sal_get_widget_dmaflush_list(u64 nasid, u64 widget_num, u64 address) +static inline u64 +sal_get_device_dmaflush_list(u64 nasid, u64 widget_num, u64 device_num, + u64 address) { struct ia64_sal_retval ret_stuff; @@ -88,17 +89,17 @@ sal_get_widget_dmaflush_list(u64 nasid, ret_stuff.v0 = 0; SAL_CALL_NOLOCK(ret_stuff, - (u64) SN_SAL_IOIF_GET_WIDGET_DMAFLUSH_LIST, - (u64) nasid, (u64) widget_num, (u64) address, 0, 0, 0, - 0); - return ret_stuff.v0; + (u64) SN_SAL_IOIF_GET_DEVICE_DMAFLUSH_LIST, + (u64) nasid, (u64) widget_num, + (u64) device_num, (u64) address, 0, 0, 0); + return ret_stuff.status; } /* * Retrieve the hub device info structure for the given nasid. */ -static inline uint64_t sal_get_hubdev_info(u64 handle, u64 address) +static inline u64 sal_get_hubdev_info(u64 handle, u64 address) { struct ia64_sal_retval ret_stuff; @@ -114,7 +115,7 @@ static inline uint64_t sal_get_hubdev_in /* * Retrieve the pci bus information given the bus number. */ -static inline uint64_t sal_get_pcibus_info(u64 segment, u64 busnum, u64 address) +static inline u64 sal_get_pcibus_info(u64 segment, u64 busnum, u64 address) { struct ia64_sal_retval ret_stuff; @@ -130,7 +131,7 @@ static inline uint64_t sal_get_pcibus_in /* * Retrieve the pci device information given the bus and device|function number. */ -static inline uint64_t +static inline u64 sal_get_pcidev_info(u64 segment, u64 bus_number, u64 devfn, u64 pci_dev, u64 sn_irq_info) { @@ -170,12 +171,12 @@ sn_pcidev_info_get(struct pci_dev *dev) */ static void sn_fixup_ionodes(void) { - - struct sn_flush_device_list *sn_flush_device_list; + struct sn_flush_device_kernel *sn_flush_device_kernel; + struct sn_flush_device_kernel *dev_entry; struct hubdev_info *hubdev; - uint64_t status; - uint64_t nasid; - int i, widget; + u64 status; + u64 nasid; + int i, widget, device; /* * Get SGI Specific HUB chipset information. @@ -186,7 +187,7 @@ static void sn_fixup_ionodes(void) nasid = cnodeid_to_nasid(i); hubdev->max_segment_number = 0xffffffff; hubdev->max_pcibus_number = 0xff; - status = sal_get_hubdev_info(nasid, (uint64_t) __pa(hubdev)); + status = sal_get_hubdev_info(nasid, (u64) __pa(hubdev)); if (status) continue; @@ -213,38 +214,49 @@ static void sn_fixup_ionodes(void) hubdev->hdi_flush_nasid_list.widget_p = kmalloc((HUB_WIDGET_ID_MAX + 1) * - sizeof(struct sn_flush_device_list *), GFP_KERNEL); - + sizeof(struct sn_flush_device_kernel *), + GFP_KERNEL); memset(hubdev->hdi_flush_nasid_list.widget_p, 0x0, (HUB_WIDGET_ID_MAX + 1) * - sizeof(struct sn_flush_device_list *)); + sizeof(struct sn_flush_device_kernel *)); for (widget = 0; widget <= HUB_WIDGET_ID_MAX; widget++) { - sn_flush_device_list = kmalloc(DEV_PER_WIDGET * - sizeof(struct - sn_flush_device_list), - GFP_KERNEL); - memset(sn_flush_device_list, 0x0, + sn_flush_device_kernel = kmalloc(DEV_PER_WIDGET * + sizeof(struct + sn_flush_device_kernel), + GFP_KERNEL); + if (!sn_flush_device_kernel) + BUG(); + memset(sn_flush_device_kernel, 0x0, DEV_PER_WIDGET * - sizeof(struct sn_flush_device_list)); + sizeof(struct sn_flush_device_kernel)); - status = - sal_get_widget_dmaflush_list(nasid, widget, - (uint64_t) - __pa - (sn_flush_device_list)); - if (status) { - kfree(sn_flush_device_list); - continue; - } + dev_entry = sn_flush_device_kernel; + for (device = 0; device < DEV_PER_WIDGET; + device++,dev_entry++) { + dev_entry->common = kmalloc(sizeof(struct + sn_flush_device_common), + GFP_KERNEL); + if (!dev_entry->common) + BUG(); + memset(dev_entry->common, 0x0, sizeof(struct + sn_flush_device_common)); + + status = sal_get_device_dmaflush_list(nasid, + widget, + device, + (u64)(dev_entry->common)); + if (status) + BUG(); - spin_lock_init(&sn_flush_device_list->sfdl_flush_lock); - hubdev->hdi_flush_nasid_list.widget_p[widget] = - sn_flush_device_list; - } + spin_lock_init(&dev_entry->sfdl_flush_lock); + } + if (sn_flush_device_kernel) + hubdev->hdi_flush_nasid_list.widget_p[widget] = + sn_flush_device_kernel; + } } - } /* diff -urNp fedora-orig/arch/ia64/sn/pci/pcibr/pcibr_dma.c fedora-work/arch/ia64/sn/pci/pcibr/pcibr_dma.c --- fedora-orig/arch/ia64/sn/pci/pcibr/pcibr_dma.c 2006-01-03 10:36:41.000000000 -0500 +++ fedora-work/arch/ia64/sn/pci/pcibr/pcibr_dma.c 2006-01-03 10:37:21.000000000 -0500 @@ -218,7 +218,9 @@ void sn_dma_flush(uint64_t addr) uint64_t flags; uint64_t itte; struct hubdev_info *hubinfo; - volatile struct sn_flush_device_list *p; + volatile struct sn_flush_device_kernel *p; + volatile struct sn_flush_device_common *common; + struct sn_flush_nasid_entry *flush_nasid_list; if (!sn_ioif_inited) @@ -268,17 +270,17 @@ void sn_dma_flush(uint64_t addr) p = &flush_nasid_list->widget_p[wid_num][0]; /* find a matching BAR */ - for (i = 0; i < DEV_PER_WIDGET; i++) { + for (i = 0; i < DEV_PER_WIDGET; i++,p++) { + common = p->common; for (j = 0; j < PCI_ROM_RESOURCE; j++) { - if (p->sfdl_bar_list[j].start == 0) + if (common->sfdl_bar_list[j].start == 0) break; - if (addr >= p->sfdl_bar_list[j].start - && addr <= p->sfdl_bar_list[j].end) + if (addr >= common->sfdl_bar_list[j].start + && addr <= common->sfdl_bar_list[j].end) break; } - if (j < PCI_ROM_RESOURCE && p->sfdl_bar_list[j].start != 0) + if (j < PCI_ROM_RESOURCE && common->sfdl_bar_list[j].start != 0) break; - p++; } /* if no matching BAR, return without doing anything. */ @@ -304,24 +306,24 @@ void sn_dma_flush(uint64_t addr) if ((1 << XWIDGET_PART_REV_NUM_REV(revnum)) & PV907516) { return; } else { - pcireg_wrb_flush_get(p->sfdl_pcibus_info, - (p->sfdl_slot - 1)); + pcireg_wrb_flush_get(common->sfdl_pcibus_info, + (common->sfdl_slot - 1)); } } else { - spin_lock_irqsave(&((struct sn_flush_device_list *)p)-> - sfdl_flush_lock, flags); - - *p->sfdl_flush_addr = 0; + spin_lock_irqsave((spinlock_t *)&p->sfdl_flush_lock, + flags); + *common->sfdl_flush_addr = 0; /* force an interrupt. */ - *(volatile uint32_t *)(p->sfdl_force_int_addr) = 1; + *(volatile uint32_t *)(common->sfdl_force_int_addr) = 1; /* wait for the interrupt to come back. */ - while (*(p->sfdl_flush_addr) != 0x10f) + while (*(common->sfdl_flush_addr) != 0x10f) cpu_relax(); /* okay, everything is synched up. */ - spin_unlock_irqrestore((spinlock_t *)&p->sfdl_flush_lock, flags); + spin_unlock_irqrestore((spinlock_t *)&p->sfdl_flush_lock, + flags); } return; } diff -urNp fedora-orig/arch/ia64/sn/pci/pcibr/pcibr_provider.c fedora-work/arch/ia64/sn/pci/pcibr/pcibr_provider.c --- fedora-orig/arch/ia64/sn/pci/pcibr/pcibr_provider.c 2006-01-03 10:36:41.000000000 -0500 +++ fedora-work/arch/ia64/sn/pci/pcibr/pcibr_provider.c 2006-01-03 10:37:21.000000000 -0500 @@ -92,7 +92,8 @@ pcibr_bus_fixup(struct pcibus_bussoft *p cnodeid_t near_cnode; struct hubdev_info *hubdev_info; struct pcibus_info *soft; - struct sn_flush_device_list *sn_flush_device_list; + struct sn_flush_device_kernel *sn_flush_device_kernel; + struct sn_flush_device_common *common; if (! IS_PCI_BRIDGE_ASIC(prom_bussoft->bs_asic_type)) { return NULL; @@ -137,20 +138,19 @@ pcibr_bus_fixup(struct pcibus_bussoft *p hubdev_info = (struct hubdev_info *)(NODEPDA(cnode)->pdinfo); if (hubdev_info->hdi_flush_nasid_list.widget_p) { - sn_flush_device_list = hubdev_info->hdi_flush_nasid_list. + sn_flush_device_kernel = hubdev_info->hdi_flush_nasid_list. widget_p[(int)soft->pbi_buscommon.bs_xid]; - if (sn_flush_device_list) { + if (sn_flush_device_kernel) { for (j = 0; j < DEV_PER_WIDGET; - j++, sn_flush_device_list++) { - if (sn_flush_device_list->sfdl_slot == -1) + j++, sn_flush_device_kernel++) { + common = sn_flush_device_kernel->common; + if (common->sfdl_slot == -1) continue; - if ((sn_flush_device_list-> - sfdl_persistent_segment == + if ((common->sfdl_persistent_segment == soft->pbi_buscommon.bs_persist_segment) && - (sn_flush_device_list-> - sfdl_persistent_busnum == + (common->sfdl_persistent_busnum == soft->pbi_buscommon.bs_persist_busnum)) - sn_flush_device_list->sfdl_pcibus_info = + common->sfdl_pcibus_info = soft; } } diff -urNp fedora-orig/include/asm-ia64/sn/sn_sal.h fedora-work/include/asm-ia64/sn/sn_sal.h --- fedora-orig/include/asm-ia64/sn/sn_sal.h 2006-01-03 10:36:41.000000000 -0500 +++ fedora-work/include/asm-ia64/sn/sn_sal.h 2006-01-03 10:37:21.000000000 -0500 @@ -75,7 +75,8 @@ #define SN_SAL_IOIF_GET_HUBDEV_INFO 0x02000055 #define SN_SAL_IOIF_GET_PCIBUS_INFO 0x02000056 #define SN_SAL_IOIF_GET_PCIDEV_INFO 0x02000057 -#define SN_SAL_IOIF_GET_WIDGET_DMAFLUSH_LIST 0x02000058 +#define SN_SAL_IOIF_GET_WIDGET_DMAFLUSH_LIST 0x02000058 // deprecated +#define SN_SAL_IOIF_GET_DEVICE_DMAFLUSH_LIST 0x0200005a #define SN_SAL_HUB_ERROR_INTERRUPT 0x02000060 #define SN_SAL_BTE_RECOVER 0x02000061 From anders at kaseorg.com Tue Jan 3 19:44:15 2006 From: anders at kaseorg.com (Anders Kaseorg) Date: Tue, 03 Jan 2006 14:44:15 -0500 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43B92BBB.9050909@cornell.edu> References: <43B92BBB.9050909@cornell.edu> Message-ID: I see this too, and suspect it is a fontconfig problem: $ time fc-list >/dev/null real 0m14.341s user 0m11.977s sys 0m0.196s $ time fc-list >/dev/null real 0m0.233s user 0m0.176s sys 0m0.048s $ time fc-list >/dev/null real 0m14.031s user 0m13.749s sys 0m0.260s $ time fc-list >/dev/null real 0m0.204s user 0m0.152s sys 0m0.048s $ time fc-list >/dev/null real 0m12.597s user 0m12.373s sys 0m0.204s ... Anders From darrellpf at gmail.com Tue Jan 3 20:16:05 2006 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 3 Jan 2006 12:16:05 -0800 Subject: bash 3.1 update Message-ID: I have very current rawhide system. This morning I updated bash, selinux, coreutils, binutils, glibc.... During the update all the install scriptlets appeared to fail. Upon rebooting my system wouldn't start since init was having problems starting prefdm. I tried booting in single user mode but at logging in just resulted in another login prompt. I tried using the FC5 test1 disk in rescue mode but it failed. I used a set of FC4 disks to boot into rescue mode. Bash had only read permission for group/other. Changing bash to rw for everyone got me a runnable system again. I was too dumb to investigate why the scriptlets didn't work, so I'm unsure if the problem is with bash or selinux, so this is just a warning to others and a suggestion of a workaround. darrell From zaitcev at redhat.com Tue Jan 3 20:17:52 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 3 Jan 2006 12:17:52 -0800 Subject: rawhide report: 20060103 changes In-Reply-To: <1136286419.2942.28.camel@laptopd505.fenrus.org> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> <1136278691.2942.5.camel@laptopd505.fenrus.org> <20060103025459.6e7642c3.zaitcev@redhat.com> <1136286419.2942.28.camel@laptopd505.fenrus.org> Message-ID: <20060103121752.2e57106a.zaitcev@redhat.com> On Tue, 03 Jan 2006 12:06:59 +0100, Arjan van de Ven wrote: > > The Broadcom is considered a shoe-in for upstream because it uses > > the softmac. And who else does? > > most other wireless is now using, or is moving to using the bscape layer > instead. Sure bscape needs a bit of work to layer on top of the existing > ieee80211 layer (like softmac does), but for me it sure isn't clear > softmac will win in the end. Heck even the broadcom driver is ported to > bscape too! Yes, there are partisans on every side, and we throw our weight behind softmac for the time being. I hope that it was thought out well between DaveJ, dwmw2, and jgarzik, because it may be a mistake, like you said. The question is, how probable. I have to say, I am not familiar with the code yet enough to know how different softmac and devicescape are. Thanks for not proposing the inclusion of madwifi at least... Something had to be done. I say, just include one, no matter which. I am sick of the uncertainty and external modules. -- Pete From sundaram at redhat.com Tue Jan 3 20:40:16 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 04 Jan 2006 02:10:16 +0530 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <200601022153.38790.jarod@wilsonet.com> References: <20051231195043.GF15058@neu.nirvana> <200601022018.02960.jarod@wilsonet.com> <6b9c17630601022133q3e7d3265r9918515cc01b89fb@mail.gmail.com> <200601022153.38790.jarod@wilsonet.com> Message-ID: <43BAE130.60507@redhat.com> Jarod Wilson wrote: >On Monday 02 January 2006 21:33, Jeff Pitman wrote: > > >>On 1/3/06, Jarod Wilson wrote: >> >> >>>On Monday 02 January 2006 18:12, Warren Togami wrote: >>> >>> >>>>If you have concerns about individual packages, please file bugs in Red >>>>Hat Bugzilla. Changes can be made to individual Core/Extras packages >>>>are usually general bug fixes and enhancements. It is wrong to expect >>>>Fedora to make special concessions only to work around problems >>>>introduced by 3rd parties. If it is the right thing to do in general >>>>cases, then it is proper to make changes to Core/Extras. >>>> >>>> >>>I'm not talking so much about problems introduced by 3rd-parties as I am >>>about problems/deficiencies uncovered by 3rd-parties, i.e., fixing >>>packages in Core in a timely fashion to eliminate the need of 3rd-party >>>packagers to replace Core components. >>> >>> >>Also, it's good to have allies on the inside. >> >> > >Very true. Most 3rd-party repos don't, apparently. > > > >>See jpackage FAQ about >>"I tried to install foo on Fedora Core 2, but got lots of error >>messages and/or things don't work": http://www.jpackage.org/faq.php >> >>Note the line: >> >>"""This issue should be fixed in Fedora Core 3, thanks to Red Hat's >>involvement in JPackage.""" >> >> > >So the anti-3rd-party repository stance isn't unilaterally applied against all >3rd-party repos, I take it? > There is no anti 3 party repository stance in the sense that there is nothing in the formal Fedora repositories working actively against them. If there are bugs in any of the packages within core they should fixed regardless of the 3rd party repositories which may have helped uncovered the problem. In other words they are just routine bugs addressed in bugzilla. No big board of (anti) cooperation required. regards Rahul From davej at redhat.com Tue Jan 3 20:50:39 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 3 Jan 2006 15:50:39 -0500 Subject: rawhide report: 20060103 changes In-Reply-To: <20060103121752.2e57106a.zaitcev@redhat.com> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> <1136278691.2942.5.camel@laptopd505.fenrus.org> <20060103025459.6e7642c3.zaitcev@redhat.com> <1136286419.2942.28.camel@laptopd505.fenrus.org> <20060103121752.2e57106a.zaitcev@redhat.com> Message-ID: <20060103205039.GH5819@redhat.com> On Tue, Jan 03, 2006 at 12:17:52PM -0800, Pete Zaitcev wrote: > > softmac will win in the end. Heck even the broadcom driver is ported to > > bscape too! > > Yes, there are partisans on every side, and we throw our weight behind > softmac for the time being. Indeed, but it shouldn't be seen as an endorsement one way or the other. > I hope that it was thought out well between DaveJ, dwmw2, and jgarzik, > because it may be a mistake, like you said. The question is, how probable. > I have to say, I am not familiar with the code yet enough to know how > different softmac and devicescape are. What's in rawhide right now may not necessarily end up in FC5. It could be whats there, it could devicescape, it could something totally different, it could be nothing. This was done mostly as an experiment to see just how well that driver works (regardless of the MAC layer) to provide something useful for the developers to beat it into shape for upstream submission. As for why this one, and no others.. Simply a manpower thing. Once this is upstream, maybe we'll tackle adm100, or ra2500 or something else. Remember, that Fedora is a test vehicle for RHEL. By the time RHEL5 ships, I'd really like to see a lot more wireless cards 'just work' out of the box with no screwing around building bits and pieces, and definitly not having to resort to ndiswrapper & friends. We're not going to get there overnight however, so we're tackling this one step at a time. I want to stress that I absolutely do *not* want to end up in a situation like the ubuntu people have with a half dozen half-baked random wireless drivers just thrown into the tree and forgotten about. I've written many times here and in other places how much I regretted merging the ipw drivers into the Fedora tree before they went upstream. It was a real pain in the ass to rebase to newer releases, and even moreso when the older version got merged upstream. This time around, with the lessons learned from that fiasco, I'm hoping things work out a little smoother. Finally, to head off the cries of hypocrisy over our 'upstream first' policy, yes, I agree it may seem we've one rule for one driver and one for another, but it comes back to that manpower thing. We can carry a few drivers, especially if we know we'll be shot of them when they get upstream soon(ish), but accepting stuff carte blanche isn't going to happen. We continue to chant that 'get it upstream' mantra, but sometimes, we'll be giving stuff a helping hand if it's something we're hacking on too, and we want to give it a little more exposure. (Especially if its something like this, which is a pain to get working). Dave From linux_4ever at yahoo.com Tue Jan 3 20:57:31 2006 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 3 Jan 2006 12:57:31 -0800 (PST) Subject: libsetrans [was Re: bash 3.1 update] In-Reply-To: Message-ID: <20060103205731.6553.qmail@web51515.mail.yahoo.com> >I was too dumb to investigate why the scriptlets didn't work, so I'm >unsure if the problem is with bash or selinux, so this is just a >warning to others and a suggestion of a workaround. I suspect this was the libsetrans update. I had to edit /etc/selinux/targeted/setrans.conf to disable the translations. Dan Walsh already has this fixed for tomorrow's rawhide...so no need to bugzilla it. The other thing I noticed was that some libraries had 2 copies installed. I have to do a rpm -Uvh --force from the yum cache to clean that up. Then I started checking the versions of other packages I installed after the scriptlets were failing. It turns out that yum/rpm deleted the rpm database entry for those packages. I had to do quite a few "yum install"s to get the rpm database back in order. This was the nastiest aspect of this bug. For example, coreutils was deleted from the database even though ls was still there. Without doing the yum install, you'll never get it to update again. -Steve __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From train at voicenet.com Tue Jan 3 21:16:48 2006 From: train at voicenet.com (Herbert Rutledge) Date: Tue, 03 Jan 2006 16:16:48 -0500 Subject: libsetrans [was Re: bash 3.1 update] In-Reply-To: <20060103205731.6553.qmail@web51515.mail.yahoo.com> References: <20060103205731.6553.qmail@web51515.mail.yahoo.com> Message-ID: <1136323008.2725.3.camel@trylon> On Tue, 2006-01-03 at 12:57 -0800, Steve G wrote: > I suspect this was the libsetrans update. I had to edit > /etc/selinux/targeted/setrans.conf to disable the translations. Dan Walsh already > has this fixed for tomorrow's rawhide...so no need to bugzilla it. You can get it today at: ftp://people.redhat.com/dwalsh/SELinux/Fedora > Then I started checking the versions of other packages I installed after the > scriptlets were failing. It turns out that yum/rpm deleted the rpm database entry > for those packages. I had to do quite a few "yum install"s to get the rpm > database back in order. The same thing happened here. > This was the nastiest aspect of this bug. What he said. -train From gianluca.cecchi at gmail.com Tue Jan 3 21:37:38 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 3 Jan 2006 22:37:38 +0100 Subject: yum updates kudzu but not its relative devel and debuginfo packages Message-ID: <561c252c0601031337h2845333fk@mail.gmail.com> yum-2.5.0-5 [root at fedora ~]# rpm -qa|grep kudz kudzu-debuginfo-1.2.16-1 kudzu-devel-1.2.16-1 kudzu-1.2.16-1 [root at fedora ~]# yum update kudzu [snip] Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for kudzu to pack into transaction set. kudzu-1.2.17-1.i386.rpm 100% |=========================| 51 kB 00:00 ---> Package kudzu.i386 0:1.2.17-1 set to be updated --> Running transaction check Dependencies Resolved ============================================================================= ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: kudzu i386 1.2.17-1 development 277 k Transaction Summary ============================================================================= Install 0 Package(s) Update 1 Package(s) Remove 0 Package(s) Total download size: 277 k Is this ok [y/N]: y Downloading Packages: (1/1): kudzu-1.2.17-1.i38 100% |=========================| 277 kB 00:02 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : kudzu ######################### [1/2] Cleanup : kudzu ######################### [2/2] Updated: kudzu.i386 0:1.2.17-1 Complete! [root at fedora ~]# rpm -qa|grep kudz kudzu-debuginfo-1.2.16-1 kudzu-devel-1.2.16-1 kudzu-1.2.17-1 [root at fedora ~]# yum update kudzu-devel kudzu-debuginfo [snip] Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: kudzu-debuginfo i386 1.2.17-1 development 384 k kudzu-devel i386 1.2.17-1 development 134 k Transaction Summary ============================================================================= Install 0 Package(s) Update 2 Package(s) Remove 0 Package(s) Total download size: 518 k Is this ok [y/N]: y Downloading Packages: (1/2): kudzu-debuginfo-1. 100% |=========================| 384 kB 00:01 (2/2): kudzu-devel-1.2.17 100% |=========================| 134 kB 00:00 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : kudzu-devel ######################### [1/4] Updating : kudzu-debuginfo ######################### [2/4] Cleanup : kudzu-debuginfo ######################### [3/4] Cleanup : kudzu-devel ######################### [4/4] Updated: kudzu-debuginfo.i386 0:1.2.17-1 kudzu-devel.i386 0:1.2.17-1 Complete! Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at j2solutions.net Tue Jan 3 21:47:26 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 03 Jan 2006 13:47:26 -0800 Subject: yum updates kudzu but not its relative devel and debuginfo packages In-Reply-To: <561c252c0601031337h2845333fk@mail.gmail.com> References: <561c252c0601031337h2845333fk@mail.gmail.com> Message-ID: <1136324846.2927.0.camel@yoda.loki.me> On Tue, 2006-01-03 at 22:37 +0100, Gianluca Cecchi wrote: > yum-2.5.0-5 > [root at fedora ~]# rpm -qa|grep kudz > kudzu-debuginfo-1.2.16-1 > kudzu-devel-1.2.16-1 > kudzu-1.2.16-1 > [root at fedora ~]# yum update kudzu kudzu-devel and kudzu-debuginfo packages most likely don't specifically depend on the exact version of kudzu-1.2.16-1, therefor when you update kudzu, no deps have been broken, and thus the other kudzu packages won't be touched. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 sundaram at redhat.com Tue Jan 3 21:47:49 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 04 Jan 2006 03:17:49 +0530 Subject: yum updates kudzu but not its relative devel and debuginfo packages In-Reply-To: <561c252c0601031337h2845333fk@mail.gmail.com> References: <561c252c0601031337h2845333fk@mail.gmail.com> Message-ID: <43BAF105.9070302@redhat.com> Hi > > [root at fedora ~]# rpm -qa|grep kudz > kudzu-debuginfo-1.2.16-1 > kudzu-devel-1.2.16-1 > kudzu-1.2.17-1 > [root at fedora ~]# yum update kudzu-devel kudzu-debuginfo > [snip] > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository > Size > ============================================================================= > > Updating: > kudzu-debuginfo i386 1.2.17-1 development > 384 k > kudzu-devel i386 1.2.17-1 development > 134 k > > Transaction Summary > ============================================================================= > > Install 0 Package(s) > Update 2 Package(s) > Remove 0 Package(s) > Total download size: 518 k > Is this ok [y/N]: y > Downloading Packages: > (1/2): kudzu-debuginfo-1. 100% |=========================| 384 kB > 00:01 > (2/2): kudzu-devel-1.2.17 100% |=========================| 134 kB 00:00 > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Updating : kudzu-devel ######################### > [1/4] > Updating : kudzu-debuginfo ######################### [2/4] > Cleanup : kudzu-debuginfo ######################### [3/4] > Cleanup : kudzu-devel ######################### > [4/4] > > Updated: kudzu-debuginfo.i386 0:1.2.17-1 kudzu-devel.i386 0:1.2.17-1 > Complete! Quite normal for many *-devel packages. This is useful on many occasions. You can install kernel-devel and build a module for a older version of the kernel for example. I think DKMS does this. regards Rahul From mpeters at mac.com Tue Jan 3 21:55:28 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 03 Jan 2006 13:55:28 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <43BAE130.60507@redhat.com> References: <20051231195043.GF15058@neu.nirvana> <200601022018.02960.jarod@wilsonet.com> <6b9c17630601022133q3e7d3265r9918515cc01b89fb@mail.gmail.com> <200601022153.38790.jarod@wilsonet.com> <43BAE130.60507@redhat.com> Message-ID: <1136325328.17625.20.camel@locolhost.localdomain> On Wed, 2006-01-04 at 02:10 +0530, Rahul Sundaram wrote: > > > There is no anti 3 party repository stance in the sense that there is > nothing in the formal Fedora repositories working actively against them. > If there are bugs in any of the packages within core they should fixed > regardless of the 3rd party repositories which may have helped uncovered > the problem. In other words they are just routine bugs addressed in > bugzilla. No big board of (anti) cooperation required. There have been cases where Extras has used a different naming scheme than the third parties - I'm not sure how many though. The extras review process is open though, and I don't know that it was ever done despite requests from the third parties against it. Nor do I think Extras should be obligated to follow third party naming schemes, not if doing so would violate the explicit extras naming scheme. From dwmw2 at infradead.org Tue Jan 3 22:26:25 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 03 Jan 2006 22:26:25 +0000 Subject: rawhide report: 20060103 changes In-Reply-To: <20060103121752.2e57106a.zaitcev@redhat.com> References: <200601030813.k038D99Q028805@porkchop.devel.redhat.com> <1136278691.2942.5.camel@laptopd505.fenrus.org> <20060103025459.6e7642c3.zaitcev@redhat.com> <1136286419.2942.28.camel@laptopd505.fenrus.org> <20060103121752.2e57106a.zaitcev@redhat.com> Message-ID: <1136327185.3707.24.camel@localhost.localdomain> On Tue, 2006-01-03 at 12:17 -0800, Pete Zaitcev wrote: > Yes, there are partisans on every side, and we throw our weight behind > softmac for the time being. > > I hope that it was thought out well between DaveJ, dwmw2, and jgarzik, > because it may be a mistake, like you said. The question is, how probable. > I have to say, I am not familiar with the code yet enough to know how > different softmac and devicescape are. As Dave said, this isn't really an endorsement, and the fact that it's in rawhide for the moment doesn't necessarily mean that it'll end up in FC5. But I think the softmac code is the best bet for now -- the others don't seem particularly interested in working to extend and fixing what we have in the kernel tree at the moment; they only want to replace the Intel IEEE 802.11 stack entirely. While they may well be right, that just isn't the way that kernel development normally works. It seems a fairly safe bet that they'll still be wittering about how much better their solution is while Johannes improves softmac to the point where it overtakes the others, and gets it merged. -- dwmw2 From florin at andrei.myip.org Wed Jan 4 04:34:29 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 03 Jan 2006 20:34:29 -0800 Subject: edit root alias when installing the OS In-Reply-To: <200601021338.00925.jarod@wilsonet.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> Message-ID: <1136349270.3368.19.camel@rivendell.home.local> On Mon, 2006-01-02 at 13:37 -0800, Jarod Wilson wrote: > On Sunday 01 January 2006 17:51, Florin Andrei wrote: > > Allowing the operator to enter an arbitrary email address to receive the > > email from root might be more realistic. > > I think I'm with Michael Peters on this one, it should go to a local user > first. Why not let the user chose? The installer should not play the nanny. To me forward to a local address would be useless in most cases, while mail loops are not a problem (I know how to configure and test email). -- Florin Andrei http://florin.myip.org/ From jarod at wilsonet.com Wed Jan 4 07:24:24 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Tue, 3 Jan 2006 23:24:24 -0800 Subject: edit root alias when installing the OS In-Reply-To: <1136349270.3368.19.camel@rivendell.home.local> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> Message-ID: <114CF008-E665-4793-AA42-74F481FA31D5@wilsonet.com> On Jan 03, 2006, at 20:34, Florin Andrei wrote: > On Mon, 2006-01-02 at 13:37 -0800, Jarod Wilson wrote: >> On Sunday 01 January 2006 17:51, Florin Andrei wrote: >>> Allowing the operator to enter an arbitrary email address to >>> receive the >>> email from root might be more realistic. >> >> I think I'm with Michael Peters on this one, it should go to a >> local user >> first. > > Why not let the user chose? The installer should not play the nanny. The installer does quite a bit of playing nanny, and I believe that's part of why anaconda is so good. > To me forward to a local address would be useless in most cases, while > mail loops are not a problem (I know how to configure and test email). My belief is that there are too many users who don't, and making it easy for them to shoot themselves in the foot would lead to more trouble than its worth. But for giggles, since I'm in the process of trying to teach myself python, perhaps I'll try to put something together that does give users the choice... -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Wed Jan 4 08:16:40 2006 From: buildsys at redhat.com (Build System) Date: Wed, 4 Jan 2006 03:16:40 -0500 Subject: rawhide report: 20060104 changes Message-ID: <200601040816.k048GeEX025112@porkchop.devel.redhat.com> Updated Packages: OpenIPMI-1.4.14-15 ------------------ * Tue Jan 03 2006 Radek Vokal 1.4.14-15 - Rebuilt against new libnetsnmp alsa-lib-1.0.10rf-4 ------------------- * Tue Jan 03 2006 Jesse Keating 1.0.10rf-4 - rebuilt amtu-1.0.4-2 ------------ * Tue Jan 03 2006 Jesse Keating 1.0.4-2 - rebuilt apr-util-1.2.2-2.2 ------------------ * Tue Jan 03 2006 Jesse Keating 1.2.2-2.2 - rebuilt again docbook-style-xsl-1.69.1-2 -------------------------- * Tue Jan 03 2006 Tim Waugh 1.69.1-2 - Patches from W. Michael Petullo: - Fix lists blocking (bug #161371). - Avoid proportional-column-width for passivetex (bug #176766). e2fsprogs-1.38-3 ---------------- * Tue Jan 03 2006 Peter Jones 1.38-3 - added support for device-mapper devices ethereal-0.10.14-3 ------------------ * Mon Jan 02 2006 Steve Dickson 0.10.14-3 - Added code to better show NFS V4 opts file-roller-2.13.3-1 -------------------- * Tue Jan 03 2006 Matthias Clasen 2.13.3-1 - Update to 2.13.3 firefox-1.5-4 ------------- * Tue Jan 03 2006 Christopher Aillon - 1.5-4 - Looks like we can build ppc64 again. Happy New Year! foomatic-3.0.2-30 ----------------- * Tue Jan 03 2006 Tim Waugh 3.0.2-30 - Updated db to 3.0-20060103. gedit-1:2.13.1-1 ---------------- * Tue Jan 03 2006 Matthias Clasen - 1:2.13.1-1 - Update to 2.13.1 - Disable scrollkeeper gettext-0.14.5-2.2 ------------------ * Tue Jan 03 2006 Jesse Keating 0.14.5-2.2 - rebuilt again glib-1:1.2.10-18.2 ------------------ * Tue Jan 03 2006 Jesse Keating 1:1.2.10-18.2 - rebuilt again gnome-desktop-2.13.4-1 ---------------------- * Tue Jan 03 2006 Matthias Clasen - 2.13.4-1 - Update to 2.13.4 gnome-games-1:2.13.4-1 ---------------------- * Tue Jan 03 2006 Matthias Clasen 1:2.13.4-1 - Update to 2.13.4 gnome-icon-theme-2.13.4-1 ------------------------- * Tue Jan 03 2006 Matthias Clasen 2.13.4-1 - Update to 2.13.4 gnome-system-monitor-2.13.4-1 ----------------------------- * Tue Jan 03 2006 Matthias Clasen 2.13.4-1 - Update to 2.13.4 gnome-utils-1:2.13.4-1 ---------------------- * Tue Jan 03 2006 Matthias Clasen 2.13.4 - Update to gnome-utils 2.13.4 - Update to gcalctool 5.7.18 gnutls-1.2.9-3 -------------- * Tue Jan 03 2006 Jesse Keating 1.2.9-3 - rebuilt gtk2-engines-2.7.2-1 -------------------- * Tue Jan 03 2006 Matthias Clasen 2.7.2-1 - Update to 2.7.2 gtkhtml3-3.9.4-1 ---------------- * Tue Jan 03 2006 David Malcolm - 3.9.4-1 - 3.9.4 howl-logger-0:0.1.8-1jpp_4fc ---------------------------- * Tue Jan 03 2006 Jesse Keating 0:0.1.8-1jpp_4fc - rebuilt again hsqldb-0:1.80.1-1jpp_5fc ------------------------ * Tue Jan 03 2006 Jesse Keating 0:1.80.1-1jpp_5fc - rebuilt again icu-3.4-6 --------- * Tue Jan 03 2006 Caolan McNamara - 3.4-6 - add icu-gcc41.patch jakarta-taglibs-standard-0:1.1.1-4jpp_2fc ----------------------------------------- * Tue Jan 03 2006 Jesse Keating - 0:1.1.1-4jpp_2fc - rebuilt again java_cup-1:0.10-0.k.1jpp_6fc ---------------------------- * Tue Jan 03 2006 Jesse Keating 1:0.10-0.k.1jpp_6fc - rebuilt again jfsutils-1.1.10-3 ----------------- * Tue Jan 03 2006 Jesse Keating - rebuilt again joram-0:4.1.5-1jpp_7fc ---------------------- * Tue Jan 03 2006 Jesse Keating 0:4.1.5-1jpp_7fc - rebuilt again kdebase-6:3.5.0-1.1 ------------------- * Fri Dec 16 2005 Jesse Keating 6:3.5.0-1.1 - rebuild for new gcc * Tue Dec 06 2005 Than Ngo 6:3.5.0-1 - add buildreq on imake kernel-2.6.15-1.1819_FC5 ------------------------ * Tue Jan 03 2006 Dave Jones - Silence some gcc4.1 warnings. * Tue Jan 03 2006 David Woodhouse - Make bcm43xx quieter when dropping packets, and make it reassociate on resume * Tue Jan 03 2006 Dave Jones - Update to 2.6.15 final. - Altix: Fix sn_flush_device_kernel & spinlock initialization. (#176827) libgnomecanvas-2.13.0-1 ----------------------- * Tue Jan 03 2006 Matthias Clasen - 2.13.0-1 - Update to 2.13.0 libgtop2-2.13.2-1 ----------------- * Tue Jan 03 2006 Matthias Clasen - Update to 2.13.2 librsvg2-2.13.3-4 ----------------- * Tue Jan 03 2006 Jesse Keating 2.13.3-4 - Rebuilt on new gcc libsetrans-0.1.14-1 ------------------- * Tue Jan 03 2006 Dan Walsh 0.1.14-1 - Fix untranslate of ""->s0 libtermcap-2.0.8-44 ------------------- * Mon Jan 02 2006 Petr Raszyk 2.0.8-44 - Rebuild. * Mon Jan 02 2006 Petr Raszyk 2.0.8-43 - libtermcap does not 'free()'memory. See #74346 A patch termcap-2.0.8-nofree.patch libwmf-0.2.8.4-3 ---------------- * Tue Jan 03 2006 Caolan McNamara 0.2.8.4-3 - add libwmf-0.2.8.4-fallbackfont.patch for rh#176620# * Fri Dec 09 2005 Jesse Keating 0.2.8.4-2.1 - rebuilt * Wed Nov 23 2005 Caolan McNamara 0.2.8.4-2 - rh#173299# modify pre/post requires libwnck-2.13.4-1 ---------------- * Tue Jan 03 2006 Matthias Clasen - 2.13.4-1 - Update to 2.13.4 metacity-2.13.8-1 ----------------- * Tue Jan 03 2006 Matthias Clasen 2.13.8-1 - Update to 2.13.8 mkinitrd-5.0.17-1 ----------------- * Tue Jan 03 2006 Peter Jones - 5.0.17-1 - fix dm operations to create/remove device nodes during each change. * Tue Jan 03 2006 Peter Jones - 5.0.16-1 - Hopefully fix raid autorun with a patch from Paul Flinders. nut-2.0.2-6 ----------- * Tue Jan 03 2006 Radek Vokal 2.0.2-6 - rebuilt against new libnetsnmp openmotif-2.3.0-0.1.2 --------------------- * Tue Jan 03 2006 Jesse Keating 2.3.0-0.1.2 - Rebuilt on new gcc pam-0.99.2.1-3 -------------- * Tue Jan 03 2006 Tomas Mraz 0.99.2.1-3 - remove 'initscripts' dependency (#176508) - update pam-redhat modules, merged patches psacct-6.3.2-38 --------------- * Tue Jan 03 2006 Ivana Varekova 6.3.2-38 - fix typo bug 176811 redhat-artwork-0.131-2 ---------------------- * Tue Jan 03 2006 John (J5) Palmieri 0.131-2 - rebuild again to fix problem with cursors not showing up redhat-menus-5.0.8-1 -------------------- * Tue Jan 03 2006 Matthias Clasen - 5.0.8-1 - Make "Other" disappear again rhythmbox-0.9.2-4 ----------------- * Tue Jan 03 2006 Jesse Keating 0.9.2-4 - rebuilt again selinux-policy-2.1.6-24 ----------------------- * Tue Jan 03 2006 Dan Walsh 2.1.6-24 - Fix "libsemanage.parse_module_headers: Data did not represent a module." problem * Tue Jan 03 2006 Dan Walsh 2.1.6-23 - Allow load_policy to read /etc/mtab thunderbird-0:1.5-0.5.5.rc1 --------------------------- * Tue Jan 03 2006 Christopher Aillon - 1.5-0.5.5.rc1 - Looks like we can build on ppc64 again. * Fri Dec 16 2005 Christopher Aillon - 1.5-0.5.4.rc1 - Rebuild * Fri Dec 16 2005 Christopher Aillon - 1.5-0.5.3.rc1 - Once again, disable ppc64 because of a new issue. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175944 - Use the system NSS libraries - Build on ppc64 tomcat5-0:5.0.30-8jpp_8fc ------------------------- * Tue Jan 03 2006 Rafael Schloming - 0:5.0.30-8jpp_7fc - Fixed typos in the init script. usermode-1.85-1 --------------- * Tue Jan 03 2006 Jindrich Novy 1.85-1 - fix userpasswd - don't crash if pam produces multi-line output (#175735) Thanks to toddp at bestweb.net - added Serbian translation (#176152) util-linux-2.13-0.13 -------------------- * Tue Jan 03 2006 Karel Zak 2.13-0.13 - fix #174676 - hwclock audit return code mismatch - fix #176441: col truncates data - fix #174111 - mount allows loopback devices to be mounted more than once to the same mount point - better wide chars usage in the cal command (based on the old 'moremisc' patch) vnc-4.1.1-33 ------------ * Tue Jan 03 2006 Tim Waugh 4.1.1-33 - Use VNC-provided Xregion (bug #176435). - Prevent restorecon error message when not present (bug #176654). xrestop-0.2-6.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnome-applets - 1:2.13.1-2.i386 requires libgtop-2.0.so.0 gnome-python2-libgtop2 - 2.12.1-8.i386 requires libgtop-2.0.so.0 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 kdeutils - 6:3.5.0-2.i386 requires libnetsnmp.so.9 openhpi - 2.2.1-1.i386 requires libnetsnmp.so.9 php-snmp - 5.1.1-7.i386 requires libnetsnmp.so.9 Broken deps for ia64 ---------------------------------------------------------- gnome-applets - 1:2.13.1-2.ia64 requires libgtop-2.0.so.0()(64bit) gnome-python2-libgtop2 - 2.12.1-8.ia64 requires libgtop-2.0.so.0()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) kdeutils - 6:3.5.0-2.ia64 requires libnetsnmp.so.9()(64bit) php-snmp - 5.1.1-7.ia64 requires libnetsnmp.so.9()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnome-applets - 1:2.13.1-2.ppc requires libgtop-2.0.so.0 gnome-python2-libgtop2 - 2.12.1-8.ppc requires libgtop-2.0.so.0 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 kdeutils - 6:3.5.0-2.ppc requires libnetsnmp.so.9 openhpi - 2.2.1-1.ppc requires libnetsnmp.so.9 php-snmp - 5.1.1-7.ppc requires libnetsnmp.so.9 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnome-applets - 1:2.13.1-2.ppc64 requires libgtop-2.0.so.0()(64bit) gnome-python2-libgtop2 - 2.12.1-8.ppc64 requires libgtop-2.0.so.0()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) kdeutils - 6:3.5.0-2.ppc64 requires libnetsnmp.so.9()(64bit) openhpi - 2.2.1-1.ppc64 requires libnetsnmp.so.9()(64bit) php-snmp - 5.1.1-7.ppc64 requires libnetsnmp.so.9()(64bit) Broken deps for s390 ---------------------------------------------------------- gnome-applets - 1:2.13.1-2.s390 requires libgtop-2.0.so.0 gnome-python2-libgtop2 - 2.12.1-8.s390 requires libgtop-2.0.so.0 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 kdeutils - 6:3.5.0-2.s390 requires libnetsnmp.so.9 openhpi - 2.2.1-1.s390 requires libnetsnmp.so.9 php-snmp - 5.1.1-7.s390 requires libnetsnmp.so.9 Broken deps for s390x ---------------------------------------------------------- gnome-applets - 1:2.13.1-2.s390x requires libgtop-2.0.so.0()(64bit) gnome-python2-libgtop2 - 2.12.1-8.s390x requires libgtop-2.0.so.0()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) kdeutils - 6:3.5.0-2.s390x requires libnetsnmp.so.9()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) openhpi - 2.2.1-1.s390x requires libnetsnmp.so.9()(64bit) php-snmp - 5.1.1-7.s390x requires libnetsnmp.so.9()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnome-applets - 1:2.13.1-2.x86_64 requires libgtop-2.0.so.0()(64bit) gnome-python2-libgtop2 - 2.12.1-8.x86_64 requires libgtop-2.0.so.0()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) kdeutils - 6:3.5.0-2.x86_64 requires libnetsnmp.so.9()(64bit) openhpi - 2.2.1-1.x86_64 requires libnetsnmp.so.9()(64bit) php-snmp - 5.1.1-7.x86_64 requires libnetsnmp.so.9()(64bit) From fedora at camperquake.de Wed Jan 4 10:04:24 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 4 Jan 2006 11:04:24 +0100 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: References: <43B92BBB.9050909@cornell.edu> Message-ID: <20060104100424.GA12961@ryoko.camperquake.de> On Tue, Jan 03, 2006 at 02:44:15PM -0500, Anders Kaseorg wrote: > I see this too, and suspect it is a fontconfig problem: I have a brand-new RH install on a PII-400 running right now and I do not see these slowdowns here. Although I do agree that RH is sluggish overall. From sundaram at redhat.com Wed Jan 4 10:11:38 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 04 Jan 2006 15:41:38 +0530 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <20060104100424.GA12961@ryoko.camperquake.de> References: <43B92BBB.9050909@cornell.edu> <20060104100424.GA12961@ryoko.camperquake.de> Message-ID: <43BB9F5A.8060902@redhat.com> Ralf Ertzinger wrote: >On Tue, Jan 03, 2006 at 02:44:15PM -0500, Anders Kaseorg wrote: > > >>I see this too, and suspect it is a fontconfig problem: >> >> > >I have a brand-new RH install on a PII-400 running right now and I do not >see these slowdowns here. > >Although I do agree that RH is sluggish overall. > > Thats pretty vague. Benchmarks, reproducible regressions, specific bug reports etc is the way to move forward with this. http://fedoraproject.org/wiki/DefaultServices for a ongoing effort. From fedora at camperquake.de Wed Jan 4 11:18:15 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 4 Jan 2006 12:18:15 +0100 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <43BB9F5A.8060902@redhat.com> References: <43B92BBB.9050909@cornell.edu> <20060104100424.GA12961@ryoko.camperquake.de> <43BB9F5A.8060902@redhat.com> Message-ID: <20060104111815.GB12961@ryoko.camperquake.de> On Wed, Jan 04, 2006 at 03:41:38PM +0530, Rahul Sundaram wrote: > Thats pretty vague. Benchmarks, reproducible regressions, specific bug > reports etc is the way to move forward with this. Yes, I know. Working on that. One thing I have established is that Clearlooks is significantly slower than bluecurce (although I can not say whether FC4-CL is faster/slower than RC-CL right now). My other gripe is Xv performance, I am writing a benchmark to get to the bottom of that one. For fun, here are some gtkperf numbers for current RH, RH default theme (mainly CL, I think) vs. bluecurve. Machine is a PII400, Number Nine T2R (yay!). 100 gtkperf iterations. The Pixbufs numbers are bogus, ignore. Default: GtkPerf 0.40 - Starting testing: Wed Jan 4 12:04:32 2006 GtkEntry - time: 0.23 GtkComboBox - time: 15.41 GtkComboBoxEntry - time: 12.34 GtkSpinButton - time: 2.19 GtkProgressBar - time: 4.74 GtkToggleButton - time: 6.19 GtkCheckButton - time: 5.98 GtkRadioButton - time: 7.51 GtkTextView - Add text - time: 7.04 GtkTextView - Scroll - time: 6.06 GtkDrawingArea - Lines - time: 4.20 GtkDrawingArea - Circles - time: 5.44 GtkDrawingArea - Text - time: 15.86 GtkDrawingArea - Pixbufs - time: 5.89 --- Total time: 99.11 Bluecurve: GtkPerf 0.40 - Starting testing: Wed Jan 4 12:08:57 2006 GtkEntry - time: 0.13 GtkComboBox - time: 6.49 GtkComboBoxEntry - time: 4.74 GtkSpinButton - time: 0.59 GtkProgressBar - time: 0.45 GtkToggleButton - time: 1.39 GtkCheckButton - time: 1.38 GtkRadioButton - time: 1.65 GtkTextView - Add text - time: 5.88 GtkTextView - Scroll - time: 5.02 GtkDrawingArea - Lines - time: 4.11 GtkDrawingArea - Circles - time: 5.35 GtkDrawingArea - Text - time: 15.84 GtkDrawingArea - Pixbufs - time: 8.31 --- Total time: 61.35 From sundaram at redhat.com Wed Jan 4 11:38:37 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 04 Jan 2006 17:08:37 +0530 Subject: Patterned slow-down over the entire GNOME desktop In-Reply-To: <20060104111815.GB12961@ryoko.camperquake.de> References: <43B92BBB.9050909@cornell.edu> <20060104100424.GA12961@ryoko.camperquake.de> <43BB9F5A.8060902@redhat.com> <20060104111815.GB12961@ryoko.camperquake.de> Message-ID: <43BBB3BD.80407@redhat.com> Ralf Ertzinger wrote: >On Wed, Jan 04, 2006 at 03:41:38PM +0530, Rahul Sundaram wrote: > > > >>Thats pretty vague. Benchmarks, reproducible regressions, specific bug >>reports etc is the way to move forward with this. >> >> > >Yes, I know. Working on that. One thing I have established is that Clearlooks >is significantly slower than bluecurce (although I can not say whether >FC4-CL is faster/slower than RC-CL right now). > >My other gripe is Xv performance, I am writing a benchmark to get to the >bottom of that one. > >For fun, here are some gtkperf numbers for current RH, RH default theme >(mainly CL, I think) vs. bluecurve. Machine is a PII400, Number Nine T2R >(yay!). 100 gtkperf iterations. The Pixbufs numbers are bogus, ignore. > > > > Ok So I created his page for tracking such efforts on a ongoing basis. What we need a list of tools and how to produce these benchmarks and document the results between various version of Fedora under different settings. We can start by tracking down and avoiding regressions. http://fedoraproject.org/wiki/Performance If you do not have edit access to the wiki already see http://fedoraproject.org/wiki/WikiEditing. Register in the FirstnameLastname format (case sensitive for wiki linking) and send me a offlist mail if you need me to add you to the edit group. From mpeters at mac.com Wed Jan 4 12:48:31 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 04 Jan 2006 04:48:31 -0800 Subject: edit root alias when installing the OS In-Reply-To: <1136349270.3368.19.camel@rivendell.home.local> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> Message-ID: <1136378912.9226.9.camel@locolhost.localdomain> On Tue, 2006-01-03 at 20:34 -0800, Florin Andrei wrote: > On Mon, 2006-01-02 at 13:37 -0800, Jarod Wilson wrote: > > On Sunday 01 January 2006 17:51, Florin Andrei wrote: > > > Allowing the operator to enter an arbitrary email address to receive the > > > email from root might be more realistic. > > > > I think I'm with Michael Peters on this one, it should go to a local user > > first. > > Why not let the user chose? The user can choose. The user can either set up the /etc/aliases file themselves - or use procmail or whatever to do the forwarding. Setting it up as a local user in firstboot is much more likely to work without problems. What happens when a user enters their e-mail address, and their e-mail server rejects it because it is coming from what looks like a compromised broadband host? (a lot of mail servers flat out reject anything that looks like it is coming from a dsl/cable modem). Now you have postfix sending a mail to root stating the message can't be delivered, which gets forwarded to the same e-mail address - meanwhile, unless the user reads the log, they may never know there is a problem. Let those who have a reason to forward root's mail to an e-mail address do so, they probably already know how - seeing as that's how they would have to do it currently. From jkeating at j2solutions.net Wed Jan 4 07:35:18 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 03 Jan 2006 23:35:18 -0800 Subject: edit root alias when installing the OS In-Reply-To: <114CF008-E665-4793-AA42-74F481FA31D5@wilsonet.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <114CF008-E665-4793-AA42-74F481FA31D5@wilsonet.com> Message-ID: <1136360118.2927.7.camel@yoda.loki.me> On Tue, 2006-01-03 at 23:24 -0800, Jarod Wilson wrote: > > My belief is that there are too many users who don't, and making it > easy for them to shoot themselves in the foot would lead to more > trouble than its worth. But for giggles, since I'm in the process of > trying to teach myself python, perhaps I'll try to put something > together that does give users the choice... Why not both? When creating a user, have a checkbox to 'deliver root's email to this user', then also have a input dialog that says 'forward this user's email to "______" address'. This way multiple users can be listed in the root alias, and each user can have their local mail delivered elsewhere if desired. Just my $0.02 -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 fedora at leemhuis.info Wed Jan 4 17:22:03 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Jan 2006 18:22:03 +0100 Subject: edit root alias when installing the OS In-Reply-To: <1136360118.2927.7.camel@yoda.loki.me> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <114CF008-E665-4793-AA42-74F481FA31D5@wilsonet.com> <1136360118.2927.7.camel@yoda.loki.me> Message-ID: <1136395323.2716.45.camel@localhost.localdomain> Am Dienstag, den 03.01.2006, 23:35 -0800 schrieb Jesse Keating: > On Tue, 2006-01-03 at 23:24 -0800, Jarod Wilson wrote: > > > > My belief is that there are too many users who don't, and making it > > easy for them to shoot themselves in the foot would lead to more > > trouble than its worth. But for giggles, since I'm in the process of > > trying to teach myself python, perhaps I'll try to put something > > together that does give users the choice... > > Why not both? When creating a user, have a checkbox to 'deliver root's > email to this user', then also have a input dialog that says 'forward > this user's email to "______" address'. This way multiple users can be > listed in the root alias, and each user can have their local mail > delivered elsewhere if desired. > > Just my $0.02 I really like the idea. BTW, the bug report #176767 that was opened during this discussion to get this fixed in the future was closed as a dupe of #135592. There one reads: > The bigger question here is why root is receiving mail in the first place. Side note: At least logwatch (daily) and sudo (in case someone tried something that is not allowed) send mails to root. The first one even is active in a default install iirc. And this is quite annoying sometimes: At my workplace the local MTA after a fresh install figures out the MX of the domain automatically and send the mails to root at ourdomain.foo -- that's quite annoying because that is somebody else that is getting upset about all these mails from systems he doesn't know anything about... > Most > people aren't going to check this even if they are aware it exists. We should > be working on a better way to inform people about what's going on with the > system instead of relying on local mail I disagree. Yes, for desktop-systems there are probably better ways to inform people. But mail is also okay IMHO. And I can't think of a better way for servers to inform the admin about problems... -- Thorsten Leemhuis From bigjoe1008 at gmail.com Wed Jan 4 18:16:02 2006 From: bigjoe1008 at gmail.com (Joseph Harnish) Date: Wed, 04 Jan 2006 13:16:02 -0500 Subject: Fedora Default Services In-Reply-To: <43BBB3BD.80407@redhat.com> References: <43B92BBB.9050909@cornell.edu> <20060104100424.GA12961@ryoko.camperquake.de> <43BB9F5A.8060902@redhat.com> <20060104111815.GB12961@ryoko.camperquake.de> <43BBB3BD.80407@redhat.com> Message-ID: <1136398562.3149.18.camel@joes-laptop.grand-rapids.mi.us> I was reading http://fedoraproject.org/wiki/DefaultServices to see what was has been talked about on it about disabling different services and I have a couple of possible additions. This is probably just a Hint for laptop users. On my laptop I use NetworkManager to handle the network connections. So I deactivated my eth0 and my wlan0 from starting when the computer boots. I had both so if I was docked it would get an IP or if I were wireless it would also work. But this slowed down my boot up a bunch. >From reading through Keith's comments it seems there is a handful of services that would come in handy for a Laptop user, some for a Desktop user and others for a Server. I think it would be a good idea to create some default service profiles. Either just document them on the wiki or actually have some default profiles in the Service Configuration tool so a newer user can just apply a profile to their system without having to know what nifd is or what rpcgssd is. Thanks Joe From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jan 4 16:55:54 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 4 Jan 2006 17:55:54 +0100 Subject: Using yum to Update to Development In-Reply-To: <43B4C02B.8020108@redhat.com> References: <004e01c60cfe$87649420$6c01a8c0@21stcenturybusiness.local> <43B4C02B.8020108@redhat.com> Message-ID: <20060104175554.4fdabc2f@python2> Rahul Sundaram wrote : > > I am trying to use yum to update one of my FC4 boxes to latest set of > > development packages. However it fails on a number of dependencies and > > I can't seem get around them even by installing them manually. Is > > there any documentation outlining the steps on upgrade from FC4 to the > > development packages. libssl.so.5 and libcrypto.so.5 seems causing > > most of the problems. > > > > --> Running transaction check > > --> Processing Dependency: libssl.so.5 for package: proftpd > > --> Processing Dependency: libcrypto.so.5 for package: proftpd > > --> Finished Dependency Resolution > > Error: Missing Dependency: libssl.so.5 is needed by package proftpd > > Error: Missing Dependency: libcrypto.so.5 is needed by package proftpd > > > Proftpd seems to be using older libs not available in the current > development tree. yum remove proftpd and try again. Kindly post to > fedora-test list for such questions in the future. Also see > http://fedoraproject.org/wiki/Docs/Drafts/TestingGuide Proftpd doesn't rebuild on current FC development. As FC5 gets nearer, I really (as the owner of the proftpd component in Extras) need to look into this... but help is welcome of course ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1653_FC4 Load : 0.19 0.20 0.18 From florin at andrei.myip.org Wed Jan 4 19:36:22 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 04 Jan 2006 11:36:22 -0800 Subject: edit root alias when installing the OS In-Reply-To: <114CF008-E665-4793-AA42-74F481FA31D5@wilsonet.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <114CF008-E665-4793-AA42-74F481FA31D5@wilsonet.com> Message-ID: <1136403382.10792.33.camel@stantz.corp.sgi.com> On Tue, 2006-01-03 at 23:24 -0800, Jarod Wilson wrote: > On Jan 03, 2006, at 20:34, Florin Andrei wrote: > > To me forward to a local address would be useless in most cases, while > > mail loops are not a problem (I know how to configure and test email). > > My belief is that there are too many users who don't, and making it > easy for them to shoot themselves in the foot would lead to more > trouble than its worth. But for giggles, since I'm in the process of > trying to teach myself python, perhaps I'll try to put something > together that does give users the choice... If the installer only allows local redirection, then it may (or not) save some newbies some trouble, but it's not a measurable improvement for more experienced users. If there's such a great concern about mail loops (which I think is unjustified, but maybe that's just me), then the installer should let the user choose between local redirection and remote forward, with the local redirection being the default. -- Florin Andrei http://florin.myip.org/ From pemboa at gmail.com Wed Jan 4 20:00:40 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 4 Jan 2006 14:00:40 -0600 Subject: edit root alias when installing the OS In-Reply-To: <1136378912.9226.9.camel@locolhost.localdomain> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> Message-ID: <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> On 1/4/06, Michael A. Peters wrote: > > On Tue, 2006-01-03 at 20:34 -0800, Florin Andrei wrote: > > On Mon, 2006-01-02 at 13:37 -0800, Jarod Wilson wrote: > > > On Sunday 01 January 2006 17:51, Florin Andrei wrote: > > > > Allowing the operator to enter an arbitrary email address to receive > the > > > > email from root might be more realistic. > > > > > > I think I'm with Michael Peters on this one, it should go to a local > user > > > first. > > > > Why not let the user chose? > > The user can choose. The user can either set up the /etc/aliases file > themselves - or use procmail or whatever to do the forwarding. > > Setting it up as a local user in firstboot is much more likely to work > without problems. > > What happens when a user enters their e-mail address, and their e-mail > server rejects it because it is coming from what looks like a > compromised broadband host? (a lot of mail servers flat out reject > anything that looks like it is coming from a dsl/cable modem). Now you > have postfix sending a mail to root stating the message can't be > delivered, which gets forwarded to the same e-mail address - meanwhile, > unless the user reads the log, they may never know there is a problem. > > Let those who have a reason to forward root's mail to an e-mail address > do so, they probably already know how - seeing as that's how they would > have to do it currently. > > You make a very good point. It seems to me, all that is needed to make your method more friendly, is some GUI that specializes it making the default user aware of mail in their local inbox. Therefore a user wouldn't have to remember to drop down to a console or setup a mail client to read their local mail in order to be aware of what we can assume to be important messages. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr.peeter at gmail.com Wed Jan 4 21:07:02 2006 From: mr.peeter at gmail.com (Peeter Puusemp) Date: Wed, 4 Jan 2006 23:07:02 +0200 Subject: SELinux adds approximately 10 seconds to the boot time Message-ID: Hi! I noticed that SELinux adds approximately 10 seconds to the boot time and Rahul Sundaram told that you may be interested in it. My system is totally updated and so uses the kernel 2.6.14-1.1653_FC4. Computer specs ------------------------ Motherboard: Epox 8rda3+ CPU: AMD AthlonXP 2500+ Barton downclocked to 1503.491 MHz (9 x 166 MHz, default is 11 x 166 MHz) Graphic card: PowerColor Radeon 9500 Memory: 512MB DDR PC3200 Adata CL3 (runs on 166 MHz) HDD: 120GB IBM 7200/8 (os is on it); 160GB Seagate 7200/8 Boot charts ----------------- With SELinux: http://img525.imageshack.us/img525/6905/bootchart43kq.png http://img271.imageshack.us/img271/3382/bootchart51sb.png Without SELinux (I disabled it in the Security Level dialog): http://img271.imageshack.us/img271/9540/bootchartselinuxita3bf.png http://img271.imageshack.us/img271/9145/bootchartselinuxita26fq.png Peeter Puusemp From kms at passback.co.uk Wed Jan 4 21:35:28 2006 From: kms at passback.co.uk (Keith Sharp) Date: Wed, 04 Jan 2006 21:35:28 +0000 Subject: Fedora Default Services In-Reply-To: <1136398562.3149.18.camel@joes-laptop.grand-rapids.mi.us> References: <43B92BBB.9050909@cornell.edu> <20060104100424.GA12961@ryoko.camperquake.de> <43BB9F5A.8060902@redhat.com> <20060104111815.GB12961@ryoko.camperquake.de> <43BBB3BD.80407@redhat.com> <1136398562.3149.18.camel@joes-laptop.grand-rapids.mi.us> Message-ID: <1136410528.15094.39.camel@animal.passback.co.uk> On Wed, 2006-01-04 at 13:16 -0500, Joseph Harnish wrote: > I was reading http://fedoraproject.org/wiki/DefaultServices to see what > was has been talked about on it about disabling different services and I > have a couple of possible additions. > > This is probably just a Hint for laptop users. On my laptop I use > NetworkManager to handle the network connections. So I deactivated my > eth0 and my wlan0 from starting when the computer boots. I had both so > if I was docked it would get an IP or if I were wireless it would also > work. But this slowed down my boot up a bunch. > > >From reading through Keith's comments it seems there is a handful of > services that would come in handy for a Laptop user, some for a Desktop > user and others for a Server. I think it would be a good idea to create > some default service profiles. Either just document them on the wiki or > actually have some default profiles in the Service Configuration tool so > a newer user can just apply a profile to their system without having to > know what nifd is or what rpcgssd is. I haven't tried a recent Rawhide (post anaconda yumification) install, is the plan to still include the different types: server, workstation, laptop, custom? If yes, then this could be used to switch between which services are to be activated. The other place, potentially, to do this is in firstboot. It is probably worth opening an RFE bugzilla against either anaconda or firstboot. Keith. From nman64 at n-man.com Wed Jan 4 22:17:28 2006 From: nman64 at n-man.com (Patrick Barnes) Date: Wed, 04 Jan 2006 16:17:28 -0600 Subject: Fedora Default Services In-Reply-To: <1136410528.15094.39.camel@animal.passback.co.uk> References: <43B92BBB.9050909@cornell.edu> <20060104100424.GA12961@ryoko.camperquake.de> <43BB9F5A.8060902@redhat.com> <20060104111815.GB12961@ryoko.camperquake.de> <43BBB3BD.80407@redhat.com> <1136398562.3149.18.camel@joes-laptop.grand-rapids.mi.us> <1136410528.15094.39.camel@animal.passback.co.uk> Message-ID: <43BC4978.209@n-man.com> Keith Sharp wrote: > On Wed, 2006-01-04 at 13:16 -0500, Joseph Harnish wrote: > > I was reading http://fedoraproject.org/wiki/DefaultServices to see what > > was has been talked about on it about disabling different services and I > > have a couple of possible additions. > > > > This is probably just a Hint for laptop users. On my laptop I use > > NetworkManager to handle the network connections. So I deactivated my > > eth0 and my wlan0 from starting when the computer boots. I had both so > > if I was docked it would get an IP or if I were wireless it would also > > work. But this slowed down my boot up a bunch. > > > > >From reading through Keith's comments it seems there is a handful of > > services that would come in handy for a Laptop user, some for a Desktop > > user and others for a Server. I think it would be a good idea to create > > some default service profiles. Either just document them on the wiki or > > actually have some default profiles in the Service Configuration tool so > > a newer user can just apply a profile to their system without having to > > know what nifd is or what rpcgssd is. > > I haven't tried a recent Rawhide (post anaconda yumification) install, > is the plan to still include the different types: server, workstation, > laptop, custom? If yes, then this could be used to switch between which > services are to be activated. The other place, potentially, to do this > is in firstboot. > > It is probably worth opening an RFE bugzilla against either anaconda or > firstboot. > > Keith. > > This is definitely not something that belongs in Anaconda. firstboot might work. Having appropriate defaults set in the RPMs would be best, then further profiles/customization can be handled post-install. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From rodd at clarkson.id.au Wed Jan 4 22:26:20 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 05 Jan 2006 09:26:20 +1100 Subject: rawhide report: 20060104 changes In-Reply-To: <200601040816.k048GeEX025112@porkchop.devel.redhat.com> References: <200601040816.k048GeEX025112@porkchop.devel.redhat.com> Message-ID: <1136413580.3125.11.camel@localhost.localdomain> On Wed, 2006-01-04 at 03:16 -0500, Build System wrote: > libgnomecanvas-2.13.0-1 > ----------------------- > * Tue Jan 03 2006 Matthias Clasen - 2.13.0-1 > - Update to 2.13.0 > Hmm, after updating this I'm getting the following error when I try to 'startx'. Interestingly, gdm won't start. The hard disk goes into a tizzy and the login never appears (this may be related to the stuff below). I switched to a terminal and then tried starting X from the command line. I get the following error: /usr/bin/gnome-session: error while loading shared libraries: libgnomecanvas-2.so.0 cannot open shared object file: No such file or directory. This is in the middle of some other Xorg output (about Synaptics stuff) but it's the only thing that seemed out of place and since I had to write it down to type in again on a different install I didn't bother to note all the other stuff (but will if someone thinks it's important. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Wed Jan 4 22:32:32 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 05 Jan 2006 09:32:32 +1100 Subject: rawhide report: 20060104 changes In-Reply-To: <1136413580.3125.11.camel@localhost.localdomain> References: <200601040816.k048GeEX025112@porkchop.devel.redhat.com> <1136413580.3125.11.camel@localhost.localdomain> Message-ID: <1136413953.3125.14.camel@localhost.localdomain> On Thu, 2006-01-05 at 09:26 +1100, Rodd Clarkson wrote: > On Wed, 2006-01-04 at 03:16 -0500, Build System wrote: > > libgnomecanvas-2.13.0-1 > > ----------------------- > > * Tue Jan 03 2006 Matthias Clasen - 2.13.0-1 > > - Update to 2.13.0 > > > Hmm, after updating this I'm getting the following error when I try to > 'startx'. > > Interestingly, gdm won't start. The hard disk goes into a tizzy and the > login never appears (this may be related to the stuff below). I > switched to a terminal and then tried starting X from the command line. > > I get the following error: > > /usr/bin/gnome-session: error while loading shared libraries: > libgnomecanvas-2.so.0 cannot open shared object file: No such file or > directory. > > This is in the middle of some other Xorg output (about Synaptics stuff) > but it's the only thing that seemed out of place and since I had to > write it down to type in again on a different install I didn't bother to > note all the other stuff (but will if someone thinks it's important. Replying to ones-self is never good. I also forgot to mention that system-config-printer didn't run because of a similar message. This was before I rebooted to the most recent rawhide kernel, but after the update. Oh and I had to exclude libgtop and gnome-system-monitor to get the update to work. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From megacoder at gmail.com Wed Jan 4 22:33:19 2006 From: megacoder at gmail.com (Tommy Reynolds) Date: Wed, 4 Jan 2006 16:33:19 -0600 Subject: edit root alias when installing the OS In-Reply-To: <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> Message-ID: Since folk appear receptive to automatically adding the root email address, could we extend a similar functionality, offering to add the first user account into /etc/sudoers? The su(8) approach is just so-o-o-o open to the dark side. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Wed Jan 4 23:06:31 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 4 Jan 2006 18:06:31 -0500 Subject: rawhide report: 20060104 changes In-Reply-To: <1136413580.3125.11.camel@localhost.localdomain> References: <200601040816.k048GeEX025112@porkchop.devel.redhat.com> <1136413580.3125.11.camel@localhost.localdomain> Message-ID: <604aa7910601041506v1929d9c3yd432ab64c376a08a@mail.gmail.com> On 1/4/06, Rodd Clarkson wrote: > I get the following error: > > /usr/bin/gnome-session: error while loading shared libraries: > libgnomecanvas-2.so.0 cannot open shared object file: No such file or > directory. thats very interesting... rpm -q --whatprovides libgnomecanvas-2.so.0 that should return libgnomecanvas-2.13.0-1 does rpm -ql libgnomecanvas show a libgnomecanvas-2.so.0 on your system? what does the /usr/lib/libgnomecanvas-2.so.0 symlink point to? did ldconfig fail to run correctly after updates? -jef From drepper at redhat.com Thu Jan 5 00:34:52 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 04 Jan 2006 16:34:52 -0800 Subject: glibc-2.3.90-26 and older kernels Message-ID: <43BC69AC.1010601@redhat.com> Tomorrow's glibc 2.3.90-26 will require be the first one which will require kernels 2.6.9 and higher. The binaries won't run on any older kernel. The spec file should contain the necessary conflicts but I thought I should point it out anyway. So, people who want to boot into older kernel, do not update glibc. Your system will be completly unusable. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwboyer at jdub.homelinux.org Thu Jan 5 00:38:49 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 04 Jan 2006 18:38:49 -0600 Subject: glibc-2.3.90-26 and older kernels In-Reply-To: <43BC69AC.1010601@redhat.com> References: <43BC69AC.1010601@redhat.com> Message-ID: <1136421529.6316.0.camel@yoda.jdub.homelinux.org> On Wed, 2006-01-04 at 16:34 -0800, Ulrich Drepper wrote: > Tomorrow's glibc 2.3.90-26 will require be the first one which will > require kernels 2.6.9 and higher. The binaries won't run on any older > kernel. The spec file should contain the necessary conflicts but I > thought I should point it out anyway. Out of curiosity... why does it require 2.6.9 and higher? thx, josh From drepper at redhat.com Thu Jan 5 00:42:11 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 04 Jan 2006 16:42:11 -0800 Subject: glibc-2.3.90-26 and older kernels In-Reply-To: <1136421529.6316.0.camel@yoda.jdub.homelinux.org> References: <43BC69AC.1010601@redhat.com> <1136421529.6316.0.camel@yoda.jdub.homelinux.org> Message-ID: <43BC6B63.3070101@redhat.com> Josh Boyer wrote: > Out of curiosity... why does it require 2.6.9 and higher? To get rid of all the compatibility crap for kernels < 2.6.9. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From naoki at valuecommerce.com Thu Jan 5 02:11:59 2006 From: naoki at valuecommerce.com (Naoki) Date: Thu, 05 Jan 2006 11:11:59 +0900 Subject: glibc-2.3.90-26 and older kernels In-Reply-To: <43BC6B63.3070101@redhat.com> References: <43BC69AC.1010601@redhat.com> <1136421529.6316.0.camel@yoda.jdub.homelinux.org> <43BC6B63.3070101@redhat.com> Message-ID: <1136427119.18235.30.camel@dragon.sys.intra> FC3 shipped with 2.6.9-1.667 by the way. So unless you're still booting with an FC2 kernel I can't see this change biting anybody. On Wed, 2006-01-04 at 16:42 -0800, Ulrich Drepper wrote: > Josh Boyer wrote: > > Out of curiosity... why does it require 2.6.9 and higher? > > To get rid of all the compatibility crap for kernels < 2.6.9. From pemboa at gmail.com Thu Jan 5 03:52:29 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 4 Jan 2006 21:52:29 -0600 Subject: edit root alias when installing the OS In-Reply-To: References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> Message-ID: <16de708d0601041952scb7728alc2cd21708120037d@mail.gmail.com> On 1/4/06, Tommy Reynolds wrote: > > Since folk appear receptive to automatically adding the root email > address, could we extend a similar functionality, offering to add the first > user account into /etc/sudoers? The su(8) approach is just so-o-o-o open to > the dark side. > > Cheers I am guilt of the su method myself. I am open to change. -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n0dalus+redhat at gmail.com Thu Jan 5 04:58:26 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 5 Jan 2006 15:28:26 +1030 Subject: edit root alias when installing the OS In-Reply-To: References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> Message-ID: <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> On 1/5/06, Tommy Reynolds wrote: > Since folk appear receptive to automatically adding the root email address, > could we extend a similar functionality, offering to add the first user > account into /etc/sudoers? The su(8) approach is just so-o-o-o open to the > dark side. > I know other distributions do this, but I don't think it is a good idea. Adding the first user to /etc/sudoers means that any malware only needs to get that user's password, or get itself to run after you use sudo, and then it gets root access. I don't see what is wrong with using su. n0dalus. From jarod at wilsonet.com Thu Jan 5 05:55:19 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Wed, 4 Jan 2006 21:55:19 -0800 Subject: edit root alias when installing the OS In-Reply-To: <1136395323.2716.45.camel@localhost.localdomain> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <114CF008-E665-4793-AA42-74F481FA31D5@wilsonet.com> <1136360118.2927.7.camel@yoda.loki.me> <1136395323.2716.45.camel@localhost.localdomain> Message-ID: On Jan 04, 2006, at 09:22, Thorsten Leemhuis wrote: > Am Dienstag, den 03.01.2006, 23:35 -0800 schrieb Jesse Keating: >> On Tue, 2006-01-03 at 23:24 -0800, Jarod Wilson wrote: >>> >>> My belief is that there are too many users who don't, and making it >>> easy for them to shoot themselves in the foot would lead to more >>> trouble than its worth. But for giggles, since I'm in the process of >>> trying to teach myself python, perhaps I'll try to put something >>> together that does give users the choice... >> >> Why not both? When creating a user, have a checkbox to 'deliver >> root's >> email to this user', then also have a input dialog that says 'forward >> this user's email to "______" address'. This way multiple users >> can be >> listed in the root alias, and each user can have their local mail >> delivered elsewhere if desired. >> >> Just my $0.02 > > I really like the idea. I'm starting to come around to it, just so long as its made blatantly obvious to the user that there could be complications. Could use some additional feedback, question coming after some background... I started out w/simply adding a checkbox to the create user module in firstboot, then today started working on a new module "Admin Email", with the intention of putting three options on it, delivery admin email to local root, to local user created on the create user screen and to an external email account, with all editing done to /etc/ aliases. I'm definitely liking the idea of only pointing /etc/aliases to other local user accounts, then creating a .forward file to move the email outside of the system, since as Jesse points out, it gives you a bit more flexibility. So now for that question... :) Create a new module, or add this all to the create user module? I think I'm leaning toward putting it all in the create user module at the moment. Here's sort of what I'm currently envisioning: Add to the user creation module - - a checkbox for "deliver root mail to this user" - another checkbox for "deliver this user's mail to an external email address - a field for the user to input an external email address Now, in my first cut, I was checking to see if there was already an alias for root, and then spitting out an error to tell the user root email was already configured to be redirected (and where), and to edit /etc/aliases to change it. Y'all think it would be better to prompt the user if a root alias is already present, asking if they want to 1) leave the root alias alone, 2) append to the root alias or 3) replace the root alias? This gets a little sticky and tedious if multiple users are created w/ in firstboot though... (does anyone do that? nb: I don't actually create ANY users in firstboot these days, I use network auth, but this is a fun and useful excercise. :) -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From mpeters at mac.com Thu Jan 5 06:51:25 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 04 Jan 2006 22:51:25 -0800 Subject: edit root alias when installing the OS In-Reply-To: References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> Message-ID: <1136443885.9226.13.camel@locolhost.localdomain> On Wed, 2006-01-04 at 16:33 -0600, Tommy Reynolds wrote: > Since folk appear receptive to automatically adding the root email > address, could we extend a similar functionality, offering to add the > first user account into /etc/sudoers? The su(8) approach is just > so-o-o-o open to the dark side. sudo is useful but is very dangerous - and the way Apple and some of the distro's implement it is absolutely stupid. If you are going to enable sudo, it has to be done extremely carefully - so that a shell can be spawned. If you can spawn a shell with sudo, then root is no safer than a regularly used login password. sudo sh Enter your user password - and now you are root. With the crappy sudo defaults that so many seem to ship. Shipping sudo w/o anything enabled by default is the right way to do it. Let the user dig their own grave, don't dig it for them by default. From sundaram at redhat.com Thu Jan 5 06:56:45 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 05 Jan 2006 12:26:45 +0530 Subject: edit root alias when installing the OS In-Reply-To: References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> Message-ID: <43BCC32D.5090107@redhat.com> Tommy Reynolds wrote: > Since folk appear receptive to automatically adding the root email > address, could we extend a similar functionality, offering to add the > first user account into /etc/sudoers? The su(8) approach is just > so-o-o-o open to the dark side. Then its better to write down why automatically enabling sudo is any better as part of the proposal. Remember that Fedora isnt squarely focused on the desktop like Mac. From sundaram at redhat.com Thu Jan 5 06:58:26 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 05 Jan 2006 12:28:26 +0530 Subject: Fedora Default Services In-Reply-To: <1136410528.15094.39.camel@animal.passback.co.uk> References: <43B92BBB.9050909@cornell.edu> <20060104100424.GA12961@ryoko.camperquake.de> <43BB9F5A.8060902@redhat.com> <20060104111815.GB12961@ryoko.camperquake.de> <43BBB3BD.80407@redhat.com> <1136398562.3149.18.camel@joes-laptop.grand-rapids.mi.us> <1136410528.15094.39.camel@animal.passback.co.uk> Message-ID: <43BCC392.80303@redhat.com> Hi >I haven't tried a recent Rawhide (post anaconda yumification) install, >is the plan to still include the different types: server, workstation, >laptop, custom? If yes, then this could be used to switch between which >services are to be activated. The other place, potentially, to do this >is in firstboot. > >It is probably worth opening an RFE bugzilla against either anaconda or >firstboot. > > It would be better to write down comments within the wiki page and discuss the efforts before you start filing bug reports. The primary focal point of bug reports should be against the packages themselves rather than Anaconda or firstboot. From jarod at wilsonet.com Thu Jan 5 06:59:07 2006 From: jarod at wilsonet.com (Jarod Wilson) Date: Wed, 4 Jan 2006 22:59:07 -0800 Subject: edit root alias when installing the OS In-Reply-To: <1136443885.9226.13.camel@locolhost.localdomain> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> Message-ID: <9B7574F2-81E3-4E15-B6C3-B75BACE4848F@wilsonet.com> On Jan 04, 2006, at 22:51, Michael A. Peters wrote: > On Wed, 2006-01-04 at 16:33 -0600, Tommy Reynolds wrote: >> Since folk appear receptive to automatically adding the root email >> address, could we extend a similar functionality, offering to add the >> first user account into /etc/sudoers? The su(8) approach is just >> so-o-o-o open to the dark side. > > sudo is useful but is very dangerous - and the way Apple and some > of the > distro's implement it is absolutely stupid. > > If you are going to enable sudo, it has to be done extremely > carefully - > so that a shell can be spawned. I presume you meant "so that a shell CAN'T be spawned". -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From russell at coker.com.au Thu Jan 5 08:12:05 2006 From: russell at coker.com.au (Russell Coker) Date: Thu, 5 Jan 2006 19:12:05 +1100 Subject: bash 3.1 update In-Reply-To: References: Message-ID: <200601051912.22409.russell@coker.com.au> On Wednesday 04 January 2006 07:16, darrell pfeifer wrote: > I have very current rawhide system. This morning I updated bash, > selinux, coreutils, binutils, glibc.... libsetrans-0.1.13-1 is broken in regard to rpm, which could potentially cause cascading failures. Best to upgrade or downgrade that package. Not sure if it's related to your problem though. > I used a set of FC4 disks to boot into rescue mode. Bash had only read > permission for group/other. Changing bash to rw for everyone got me a > runnable system again. You certainly don't want rw for everyone! Bash should be mode 0755 or similar, r-x for everyone. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From peter.bieshaar at gmail.com Thu Jan 5 13:00:09 2006 From: peter.bieshaar at gmail.com (Peter Bieshaar) Date: Thu, 5 Jan 2006 14:00:09 +0100 Subject: bash 3.1 update In-Reply-To: <200601051912.22409.russell@coker.com.au> References: <200601051912.22409.russell@coker.com.au> Message-ID: <529f9df20601050500s17725ab7x@mail.gmail.com> agree to all above, if I create a package (normally under Solaris, sorry I'm a Solaris person and spying on you :) ) I make the permissions as strict as possible. IMHO there is normally no reason WHY a binary executable should be readable. I checked my laptop (FC4) and saw the permissions indeed 755 for bash. A 111 (---x--x--x) is normally enough for a binary. In very rare cases a suid/sgid should (not) be set (see my grey hair).The kernel will still read it though magic and kernel drivers. Script permissions is another story off-course. My strategy is to make it as difficult as much to myself and try to secure the system from bottom-up. In other words, I should re-define permissions as strict as possible in the rpm. But that is another discussion. This might be a point for FC6?? 2006/1/5, Russell Coker : > > On Wednesday 04 January 2006 07:16, darrell pfeifer > wrote: > > I have very current rawhide system. This morning I updated bash, > > selinux, coreutils, binutils, glibc.... > > libsetrans-0.1.13-1 is broken in regard to rpm, which could potentially > cause > cascading failures. Best to upgrade or downgrade that package. Not sure > if > it's related to your problem though. > > > I used a set of FC4 disks to boot into rescue mode. Bash had only read > > permission for group/other. Changing bash to rw for everyone got me a > > runnable system again. > > You certainly don't want rw for everyone! Bash should be mode 0755 or > similar, r-x for everyone. > > -- > http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages > http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark > http://www.coker.com.au/postal/ Postal SMTP/POP benchmark > http://www.coker.com.au/~russell/ My home page > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Peter Bieshaar NL(0)6 29577255 -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell at coker.com.au Thu Jan 5 14:02:27 2006 From: russell at coker.com.au (Russell Coker) Date: Fri, 6 Jan 2006 01:02:27 +1100 Subject: bash 3.1 update In-Reply-To: <529f9df20601050500s17725ab7x@mail.gmail.com> References: <200601051912.22409.russell@coker.com.au> <529f9df20601050500s17725ab7x@mail.gmail.com> Message-ID: <200601060102.47149.russell@coker.com.au> On Friday 06 January 2006 00:00, Peter Bieshaar wrote: > IMHO there is normally no reason WHY a binary executable should be > readable. I checked my laptop (FC4) and saw the permissions indeed 755 for > bash. A 111 (---x--x--x) is normally enough for a binary. In the case of programs shipped as part of Fedora every computer user in the world can get a copy of them, so there is not anything secret. There is a significant usability benefit in having the files world readable. For example just say you use a Fedora machine and after an upgrade gpg crashes (which just happened in rawhide incidentally). The first thing you might suspect is that the gpg binary was corrupt, the solution to this is to copy the binary from another machine for test purposes. The other machine in question may be one one which you don't have root access or it may be that you don't want to change to the root account for such a trivial operation (think shoulder-surfing). > In very rare > cases a suid/sgid should (not) be set (see my grey hair). I'm not sure what you are saying here. You may be referencing the idea that SUID binaries should be mode 4711 so that users can't read them to search for security holes, but the fact that everyone in the world can get access to them blows that out of the water. It may be that you don't want a potentially hostile user to know the version of a program that you have installed, but a regular user can run "rpm -qa" to get such information and more. > My strategy is to make it as difficult as much to myself and try to secure > the system from bottom-up. In other words, I should re-define permissions > as strict as possible in the rpm. But that is another discussion. Have you tried the "strict" SE Linux policy? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From jdesbonnet at gmail.com Thu Jan 5 14:04:17 2006 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Thu, 5 Jan 2006 14:04:17 +0000 Subject: CD Eject Message-ID: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> There is one really, really cool feature MS Windows has which I've never seen implemented on any Linux distro: You press the CD Eject button and the CD ejects (always!) I know it's not the unix way, but is there any reason why this can't be done? .. given that USB stick drives can be yanked out without the machine exploding, why not CD/DVDs? In recent years the only reasons why my Linux computer gets rebooted is: 1. Upgrade 2. Power failure 3. CD/DVD refuses to eject and someone needs it in a hurry :-) Joe. From sds at tycho.nsa.gov Thu Jan 5 14:33:08 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 05 Jan 2006 09:33:08 -0500 Subject: SELinux adds approximately 10 seconds to the boot time In-Reply-To: References: Message-ID: <1136471588.27632.391.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-01-04 at 23:07 +0200, Peeter Puusemp wrote: > Hi! > > I noticed that SELinux adds approximately 10 seconds to the boot time > and Rahul Sundaram told that you may be interested in it. My system is > totally updated and so uses the kernel 2.6.14-1.1653_FC4. Some optimizations have gone into libselinux and udev in rawhide to reduce the SELinux-related overhead in udev. -- Stephen Smalley National Security Agency From alan at redhat.com Thu Jan 5 14:31:53 2006 From: alan at redhat.com (Alan Cox) Date: Thu, 5 Jan 2006 09:31:53 -0500 Subject: bash 3.1 update In-Reply-To: <529f9df20601050500s17725ab7x@mail.gmail.com> References: <200601051912.22409.russell@coker.com.au> <529f9df20601050500s17725ab7x@mail.gmail.com> Message-ID: <20060105143153.GA909@devserv.devel.redhat.com> On Thu, Jan 05, 2006 at 02:00:09PM +0100, Peter Bieshaar wrote: > IMHO there is normally no reason WHY a binary executable should be readable. > I checked my laptop (FC4) and saw the permissions indeed 755 for bash. A 111 > (---x--x--x) is normally enough for a binary. In very rare cases a suid/sgid If you give 'r' then users are permitted to see as well as execute the binary. This is neccessary to get core dumps or use a debugger. Lets face it the binary image of bash is not a state secret and downloadable from redhat.com. Setting x only might well make sense on other software such as non-free packages that most not be "borrowed" by end users From prushinsky at gmail.com Thu Jan 5 14:36:10 2006 From: prushinsky at gmail.com (Yuri Prushinsky) Date: Thu, 05 Jan 2006 17:36:10 +0300 Subject: CD Eject In-Reply-To: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> Message-ID: <43BD2EDA.9070601@gmail.com> Joe, seems that supermount patch for linux kernel was designed for this purpose and was implemented in Mandrake linux distros Joe Desbonnet wrote: > There is one really, really cool feature MS Windows has which I've > never seen implemented on any Linux distro: You press the CD Eject > button and the CD ejects (always!) > > I know it's not the unix way, but is there any reason why this can't > be done? .. given that USB stick drives can be yanked out without the > machine exploding, why not CD/DVDs? > > In recent years the only reasons why my Linux computer gets rebooted is: > 1. Upgrade > 2. Power failure > 3. CD/DVD refuses to eject and someone needs it in a hurry :-) > > Joe. > -- Sincerely yours, Yura From tmus at tmus.dk Thu Jan 5 14:57:53 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 05 Jan 2006 15:57:53 +0100 Subject: CD Eject In-Reply-To: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> Message-ID: Joe Desbonnet wrote: > There is one really, really cool feature MS Windows has which I've > never seen implemented on any Linux distro: You press the CD Eject > button and the CD ejects (always!) > > I know it's not the unix way, but is there any reason why this can't > be done? .. given that USB stick drives can be yanked out without the > machine exploding, why not CD/DVDs? > > In recent years the only reasons why my Linux computer gets rebooted is: > 1. Upgrade > 2. Power failure > 3. CD/DVD refuses to eject and someone needs it in a hurry :-) > > Joe. > Actually, IIRC, windows (or the drive itself) locks the drive door too under operation, but the lock is released, as soon as it's not in use... Anyways, there are plenty automounting variants available that allows this to work in one way or the other... Hope this helps... /Thomas From ph18 at cornell.edu Thu Jan 5 16:04:57 2006 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 05 Jan 2006 11:04:57 -0500 Subject: edit root alias when installing the OS In-Reply-To: References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> Message-ID: <43BD43A9.2070403@cornell.edu> Tommy Reynolds wrote: > Since folk appear receptive to automatically adding the root email > address, could we extend a similar functionality, offering to add the > first user account into /etc/sudoers? The su(8) approach is just > so-o-o-o open to the dark side. > > Cheers Yes, anything that expands the culture of sudo is a good thing. From dhollis at davehollis.com Thu Jan 5 16:33:10 2006 From: dhollis at davehollis.com (David Hollis) Date: Thu, 05 Jan 2006 11:33:10 -0500 Subject: glibc-2.3.90-26 and older kernels In-Reply-To: <1136427119.18235.30.camel@dragon.sys.intra> References: <43BC69AC.1010601@redhat.com> <1136421529.6316.0.camel@yoda.jdub.homelinux.org> <43BC6B63.3070101@redhat.com> <1136427119.18235.30.camel@dragon.sys.intra> Message-ID: <1136478790.2509.4.camel@dhollis-lnx.sunera.com> On Thu, 2006-01-05 at 11:11 +0900, Naoki wrote: > FC3 shipped with 2.6.9-1.667 by the way. So unless you're still booting > with an FC2 kernel I can't see this change biting anybody. > > On Wed, 2006-01-04 at 16:42 -0800, Ulrich Drepper wrote: > > Josh Boyer wrote: > > > Out of curiosity... why does it require 2.6.9 and higher? > > > > To get rid of all the compatibility crap for kernels < 2.6.9. > It'll hit somebody who feels the need to keep that old 2.0.30 kernel running or something.... And it'll start a big flamewar about how RedHat keeps hosing people over because they are slaves to the almighty dollar and don't care about the FOSS community. It'll then melt into a Gnome vs KDE debate and various folks will chime in with "thats why I run Gentoo now!"... Out of curiosity though, how much compatibility cruft has built up over all this time? Is it a size issue? Maintenance? Performance even? -------------- 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 Thu Jan 5 16:36:36 2006 From: dhollis at davehollis.com (David Hollis) Date: Thu, 05 Jan 2006 11:36:36 -0500 Subject: rawhide report: 20060104 changes In-Reply-To: <1136413580.3125.11.camel@localhost.localdomain> References: <200601040816.k048GeEX025112@porkchop.devel.redhat.com> <1136413580.3125.11.camel@localhost.localdomain> Message-ID: <1136478996.2509.8.camel@dhollis-lnx.sunera.com> On Thu, 2006-01-05 at 09:26 +1100, Rodd Clarkson wrote: > On Wed, 2006-01-04 at 03:16 -0500, Build System wrote: > > libgnomecanvas-2.13.0-1 > > ----------------------- > > * Tue Jan 03 2006 Matthias Clasen - 2.13.0-1 > > - Update to 2.13.0 > > > Hmm, after updating this I'm getting the following error when I try to > 'startx'. > > This is in the middle of some other Xorg output (about Synaptics stuff) > but it's the only thing that seemed out of place and since I had to > write it down to type in again on a different install I didn't bother to > note all the other stuff (but will if someone thinks it's important. Maybe it's not related, or maybe it is but.... I did a fresh install just the other day (minimal FC4 since I had the media handy, and then updated to Rawhide) and had some odd issues with Gnome. It seemed that certain RPMs didn't want to install properly for some odd reason. After reinstalling a few RPMS (avahi was one that was being a problem as I recall), I was getting farther, but then Gnome didn't display any icons or images. It turned out that gtk2 was hosed for some reason. Reinstalling it made everything start to work normally. -------------- 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 buildsys at redhat.com Thu Jan 5 17:24:13 2006 From: buildsys at redhat.com (Build System) Date: Thu, 5 Jan 2006 12:24:13 -0500 Subject: rawhide report: 20060105 changes Message-ID: <200601051724.k05HODpM026861@porkchop.devel.redhat.com> New package gstreamer-plugins-base GStreamer streaming media framework base plug-ins New package gstreamer-plugins-good GStreamer plug-ins with good code and licensing New package gstreamer08 GStreamer streaming media framework runtime. New package gstreamer08-plugins GStreamer Streaming media framework plug-ins Updated Packages: apr-1.2.2-7 ----------- * Wed Jan 04 2006 Joe Orton 1.2.2-7 - fix namespace pollution (r354824, r355464) * Wed Jan 04 2006 Joe Orton 1.2.2-6 - fix build with recent glibc (#176911) * Tue Jan 03 2006 Jesse Keating 1.2.2-5.2 - rebuilt again boost-1.33.1-3 -------------- * Wed Jan 04 2006 Benjamin Kosnik 1.33.1-3 - Update to boost-1.33.1. - (#176485: Missing BuildRequires) - (#169271: /usr/lib/libboost*.so.? links missing in package) checkpolicy-1.28-3 ------------------ * Wed Jan 04 2006 Dan Walsh 1.28-3 - Rebuild to get latest libsepol compat-gcc-296-2.96-134 ----------------------- compat-gcc-32-3.2.3-54.fc5 -------------------------- control-center-1:2.13.4-1 ------------------------- * Wed Jan 04 2006 Matthias Clasen - 1:2.13.4-1 - Update to 2.13.4 coreutils-5.93-7 ---------------- * Thu Jan 05 2006 Tim Waugh 5.93-7 - Don't suppress chown/chgrp errors in install(1) (bug #176708). crash-4.0-2.18 -------------- * Wed Jan 04 2006 Dave Anderson 4.0-2.18 - Updated source package to crash-4.0.tar.gz, and crash.patch to bring it up to 4.0-2.18. * Fri Dec 09 2005 Jesse Keating - rebuilt cups-1:1.1.23-28 ---------------- * Wed Jan 04 2006 Tim Waugh 1:1.1.23-28 - Apply patch to fix CVE-2005-3625, CVE-2005-3626, CVE-2005-3627 (bug #176868). e2fsprogs-1.38-4 ---------------- * Wed Jan 04 2006 Peter Jones 1.38-4 - fix a logic error in dm probing - add priority group for dm devices, so they'll be preferred evolution-2.5.4-2 ----------------- * Wed Jan 04 2006 David Malcolm - 2.5.4-2 - added optional build-time requirement on NetworkManager-glib-devel - update patch 805 to cover a missing declaration in Network Manager support * Tue Jan 03 2006 David Malcolm - 2.5.4-1 - 2.5.4 - update patch 107 to track underlying code changes; rename from evolution-2.2.2-move-autosave-file.patch to evolution-2.5.4-move-autosave-file.patch - added patch to fix more missing declarations (patch 805) - added files for publish-calendar plugin * Mon Dec 19 2005 David Malcolm - 2.5.3-1 - 2.5.3 - Updated patch 106 (evolution-2.2.2-commit-enter-on-calendar.patch) so that it still applies cleanly evolution-connector-2.5.4-1 --------------------------- * Wed Jan 04 2006 David Malcolm - 2.5.4-1 - 2.5.4 evolution-data-server-1.5.4-1 ----------------------------- * Tue Jan 03 2006 David Malcolm - 1.5.4-1 - 1.5.4 glibc-2.3.90-26 --------------- * Wed Jan 04 2006 Jakub Jelinek 2.3.90-26 - update from CVS - for newly linked lio_listio* callers, send per request notifications (#170116) - fixup nscd -S option removal changes (#176860) - remove nonnull attribute from ctermid (#176753) - fix PTHREAD_*_INITIALIZER{,_NP} on 64-bit arches - SPARC NPTL support for pre-v9 CPUs - drop support for 2.4.xx and < 2.6.9 kernels gnome-applets-1:2.13.1-3 ------------------------ * Wed Jan 04 2006 Matthias Clasen 2.13.1-3 - Rebuild against new libgtop gnome-volume-manager-1.5.7-2 ---------------------------- * Wed Jan 04 2006 John (J5) Palmieri - 1.5.7-2 - Added a patch to fix an array being passed to dbus gphoto2-2.1.99-1 ---------------- * Thu Jan 05 2006 Radek Vokal 2.1.99-1 - upgrade to 2.1.99 + dbus patch groff-1.18.1.1-6 ---------------- * Thu Jan 05 2006 Jindrich Novy - 1.18.1.1-6 - add BuildRequires imake and update dependencies for modular X - spec cleanup - fix compilation with gcc-4.1.0 gstreamer-0.10.0-1 ------------------ * Fri Dec 16 2005 Thomas Vander Stichele - 0.10.0-1 - rebuilt for Fedora Core Development * Wed Dec 14 2005 Thomas Vander Stichele - 0.10.0-0.gst.2 - rebuilt against newer GLib and friends * Mon Dec 05 2005 Thomas Vander Stichele - 0.10.0-0.gst.1 - new release gthumb-2.7.2-1 -------------- * Wed Jan 04 2006 Matthias Clasen - 2.7.2-1 - Update to 2.7.2 - Drop upstreamed patches gtksourceview-1.5.4-1 --------------------- * Thu Jan 05 2006 Matthias Clasen - Update to 1.5.4 * Tue Jan 03 2006 Matthias Clasen - Update to 1.5.3 hplip-0.9.7-7 ------------- * Thu Jan 05 2006 Tim Waugh 0.9.7-7 - Fix initscript (bug #176966). httpd-2.2.0-4 ------------- * Thu Jan 05 2006 Joe Orton 2.2.0-4 - mod_proxy_ajp: fix Cookie handling (Mladen Turk, r358769) java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_59rh ------------------------------------------ * Wed Jan 04 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_59rh - Import java-gcj-compat 1.0.47. * Wed Jan 04 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_58rh - Import java-gcj-compat 1.0.46. jotm-0:2.0.5-1jpp_6fc --------------------- * Fri Dec 23 2005 Archit Shah 0:2.0.5-1jpp_6fc - Replace bz133180 patch with one that disables iiop stub compilation. kdeutils-6:3.5.0-3 ------------------ * Thu Jan 05 2006 Radek Vokal 6:3.5.0-3 - rebuilt against new libnetsnmp libaio-0.3.106-2 ---------------- * Wed Jan 04 2006 Jeff Moyer - 0.3.106-2 - Update to the latest sources, which contain the following change: Add a .proc directive for the ia64_aio_raw_syscall macro. This sounds a lot like the previous entry, but that one fixed the __ia64_raw_syscall macro, located in syscall-ia64.h. This macro is in raw_syscall.c, which pretty much only exists for ia64. This bug prevented the package from building with newer version of gcc. * Fri Dec 09 2005 Jesse Keating - rebuilt libc-client-2004g-1 ------------------- * Thu Jan 05 2006 Jonathan Kamens 2004g-1 - Upstream version 2004g (#176974) - Remove obsolete doc file "WARNING" - Remove security patch included in new upstream version - Custom flock code no longer necessary; included in upstream libselinux-1.29.3-2 ------------------- * Wed Jan 04 2006 Dan Walsh 1.29.4-1 - Build with new libsepol * Wed Jan 04 2006 Dan Walsh 1.29.3-1 - Upgrade to latest from NSA * Merged several fixes and improvements from Ulrich Drepper (Red Hat), including: - corrected use of getline - further calls to __fsetlocking for local files - use of strdupa and asprintf - proper handling of dirent in booleans code - use of -z relro - several other optimizations * Merged getpidcon python wrapper from Dan Walsh (Red Hat). libsemanage-1.5.4-1 ------------------- * Thu Jan 05 2006 Dan Walsh 1.5.4-1 - Upgrade to latest from NSA * Merged patch series from Ivan Gyurdiev. This includes patches to: - separate file rw code from linked list - annotate objects - fold together internal headers - support ordering of records in compare function - add active dbase backend, active booleans - return commit numbers for ro database calls - use modified flags to skip rebuild whenever possible - enable port interfaces - update swig interfaces and typemaps - add an API for file_contexts.local and file_contexts - flip the traversal order in iterate/list - reorganize sandbox_expand - add seusers MLS validation - improve dbase spec/documentation - clone record on set/add/modify libsepol-1.11.4-1 ----------------- * Thu Jan 05 2006 Dan Walsh 1.11.4-1 - Upgrade to latest from NSA * Merged bugfix for sepol_port_modify from Russell Coker. * Fixed bug in sepol_iface_modify error path noted by Ivan Gyurdiev. * Merged port ordering patch from Ivan Gyurdiev. * Wed Jan 04 2006 Dan Walsh 1.11.2-2 - Upgrade to latest from NSA * Merged patch series from Ivan Gyurdiev. This includes patches to: - support ordering of records in compare function - enable port interfaces - add interfaces for context validity and range checks - add include guards libsetrans-0.1.15-1 ------------------- * Wed Jan 04 2006 Dan Walsh 0.1.15-1 - Eliminate a couple of checks after strdupa, fix return on all paths libxml2-2.6.23-1 ---------------- * Thu Jan 05 2006 Daniel Veillard - upstream release 2.6.23 see http://xmlsoft.org/news.html * Thu Jan 02 2003 Daniel Veillard - integrated drv_libxml2 xml.sax driver from St?phane Bidoul - provides the new XmlTextReader interfaces based on C# XML APIs * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems mysql-5.0.18-1 -------------- * Thu Jan 05 2006 Tom Lane 5.0.18-1 - Update to MySQL 5.0.18 * Thu Dec 15 2005 Tom Lane 5.0.16-4 - fix my_config.h for ppc platforms * Thu Dec 15 2005 Tom Lane 5.0.16-3 - my_config.h needs to guard against 64-bit platforms that also define the 32-bit symbol openoffice.org-1:2.0.1.1-5.2 ---------------------------- * Wed Jan 04 2006 Caolan McNamara - 1:2.0.1.1-5 - spinbutton factory needs to be uneditable as well as combobox - add openoffice.org-2.0.1-ooo19976.framework.nofocussteal.patch for jrb * Thu Dec 22 2005 Caolan McNamara - 1:2.0.1.1-4 - add openoffice.org-2.0.1-ooo59997.sw.defaultbullets.patch for rh#176779# opensp-1.5.2-1 -------------- * Thu Jan 05 2006 Tim Waugh 1.5.2-1 - 1.5.2. pam_ccreds-3-2 -------------- * Wed Jan 04 2006 Tomas Mraz - 3-2 - the path to ccreds_validate helper was wrong * Wed Jan 04 2006 Tomas Mraz - 3-1 - new upstream version - added patch (slightly modified) by W. Michael Petullo to support operation from non-root accounts (#151914) php-5.1.1-8 ----------- * Thu Jan 05 2006 Joe Orton 5.1.1-8 - rebuild again policycoreutils-1.29.3-1 ------------------------ * Wed Jan 04 2006 Dan Walsh 1.29.3-1 - Update to match NSA * Merged semanage getpwnam bug fix from Serge Hallyn (IBM). * Merged patch series from Ivan Gyurdiev. This includes patches to: - cleanup setsebool - update setsebool to apply active booleans through libsemanage - update semodule to use the new semanage_set_rebuild() interface - fix various bugs in semanage * Merged patch from Dan Walsh (Red Hat). This includes fixes for restorecon, chcat, fixfiles, genhomedircon, and semanage. pup-0.9.1-1 ----------- * Wed Jan 04 2006 Jeremy Katz - 0.9.1-1 - fix a silly traceback * Wed Jan 04 2006 Jeremy Katz - 0.9.0-1 - Require pygtk2-libglade (#176292) - Moved some generic bits down into yum - Set the title on dialog boxes - Handle errors running transactions (#174500) - Wait for confirmation on the reboot - Log to the yum logfile (#163785, #175808) - Make progress bar not jump (#176407) - Use rhpl exception handler - Move to System Tools menu python-pyblock-0.10-1 --------------------- * Wed Jan 04 2006 Peter Jones - 0.10-1 - fix checking for "degraded" raids ruby-1.8.4-2 ------------ * Wed Jan 04 2006 Akira TAGOH - 1.8.4-2 - ruby-tcltk-multilib.patch: fixed a typo. * Tue Dec 27 2005 Akira TAGOH - 1.8.4-1 - New upstream release. - fixed a missing return statement. (#140833) - fixed an use of uninitialized variable. (#144890) selinux-policy-2.1.7-1 ---------------------- * Wed Jan 04 2006 Dan Walsh 2.1.7-1 - Update to upstream subversion-1.3.0-2 ------------------ * Wed Jan 04 2006 Joe Orton 1.3.0-2 - update to 1.3.0 (#176833) - update to psvn.el r17921 Stefan Reichoer system-config-date-1.7.99.12-1 ------------------------------ * Wed Jan 04 2006 Nils Philippsen 1.7.99.12 - show actually chosen region, not just something that's in the vicinity * Fri Dec 30 2005 Nils Philippsen - fix highlighted regions when leaving and entering the timeone map canvas - make timezone list a treeview - update timezone po source file system-config-kickstart-2.6.3-1 ------------------------------- * Wed Jan 04 2006 Chris Lumens 2.6.3-1 - Remove references to monitor in xconfig (#176537). system-config-printer-0.6.147-1 ------------------------------- * Thu Jan 05 2006 Tim Waugh 0.6.147-1 - 0.6.147: - Don't alter page margins (bug #176906). zsh-4.2.5-1.2 ------------- * Wed Jan 04 2006 Jesse Keating 0 4.2.5-1.2 - rebuilt again * Fri Dec 09 2005 Jesse Keating - rebuilt Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnome-applets - 1:2.13.1-3.i386 requires gstreamer-plugins >= 0:0.7.6-2 gnome-python2-libgtop2 - 2.12.1-8.i386 requires libgtop-2.0.so.0 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 libofx - 0.8.0-1.i386 requires libosp.so.4 openhpi - 2.2.1-1.i386 requires libnetsnmp.so.9 openjade - 1.3.2-22.i386 requires libosp.so.4 sound-juicer - 2.13.1-2.1.i386 requires gstreamer-plugins totem - 1.3.0-1.i386 requires gstreamer-plugins >= 0:0.8.5 Broken deps for ia64 ---------------------------------------------------------- gnome-applets - 1:2.13.1-3.ia64 requires gstreamer-plugins >= 0:0.7.6-2 gnome-python2-libgtop2 - 2.12.1-8.ia64 requires libgtop-2.0.so.0()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) libofx - 0.8.0-1.ia64 requires libosp.so.4()(64bit) openjade - 1.3.2-22.ia64 requires libosp.so.4()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs sound-juicer - 2.13.1-2.1.ia64 requires gstreamer-plugins totem - 1.3.0-1.ia64 requires gstreamer-plugins >= 0:0.8.5 Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnome-applets - 1:2.13.1-3.ppc requires gstreamer-plugins >= 0:0.7.6-2 gnome-python2-libgtop2 - 2.12.1-8.ppc requires libgtop-2.0.so.0 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 libofx - 0.8.0-1.ppc requires libosp.so.4 openhpi - 2.2.1-1.ppc requires libnetsnmp.so.9 openjade - 1.3.2-22.ppc requires libosp.so.4 sound-juicer - 2.13.1-2.1.ppc requires gstreamer-plugins totem - 1.3.0-1.ppc requires gstreamer-plugins >= 0:0.8.5 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnome-applets - 1:2.13.1-3.ppc64 requires gstreamer-plugins >= 0:0.7.6-2 gnome-python2-libgtop2 - 2.12.1-8.ppc64 requires libgtop-2.0.so.0()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) libofx - 0.8.0-1.ppc64 requires libosp.so.4()(64bit) openhpi - 2.2.1-1.ppc64 requires libnetsnmp.so.9()(64bit) openjade - 1.3.2-22.ppc64 requires libosp.so.4()(64bit) sound-juicer - 2.13.1-2.1.ppc64 requires gstreamer-plugins totem - 1.3.0-1.ppc64 requires gstreamer-plugins >= 0:0.8.5 Broken deps for s390 ---------------------------------------------------------- gnome-applets - 1:2.13.1-3.s390 requires gstreamer-plugins >= 0:0.7.6-2 gnome-python2-libgtop2 - 2.12.1-8.s390 requires libgtop-2.0.so.0 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 libofx - 0.8.0-1.s390 requires libosp.so.4 openhpi - 2.2.1-1.s390 requires libnetsnmp.so.9 openjade - 1.3.2-22.s390 requires libosp.so.4 totem - 1.3.0-1.s390 requires gstreamer-plugins >= 0:0.8.5 Broken deps for s390x ---------------------------------------------------------- gnome-applets - 1:2.13.1-3.s390x requires gstreamer-plugins >= 0:0.7.6-2 gnome-python2-libgtop2 - 2.12.1-8.s390x requires libgtop-2.0.so.0()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libofx - 0.8.0-1.s390x requires libosp.so.4()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) openhpi - 2.2.1-1.s390x requires libnetsnmp.so.9()(64bit) openjade - 1.3.2-22.s390x requires libosp.so.4()(64bit) openjade - 1.3.2-22.s390 requires libosp.so.4 totem - 1.3.0-1.s390x requires gstreamer-plugins >= 0:0.8.5 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnome-applets - 1:2.13.1-3.x86_64 requires gstreamer-plugins >= 0:0.7.6-2 gnome-python2-libgtop2 - 2.12.1-8.x86_64 requires libgtop-2.0.so.0()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) libofx - 0.8.0-1.x86_64 requires libosp.so.4()(64bit) openhpi - 2.2.1-1.x86_64 requires libnetsnmp.so.9()(64bit) openjade - 1.3.2-22.i386 requires libosp.so.4 openjade - 1.3.2-22.x86_64 requires libosp.so.4()(64bit) sound-juicer - 2.13.1-2.1.x86_64 requires gstreamer-plugins totem - 1.3.0-1.x86_64 requires gstreamer-plugins >= 0:0.8.5 From Tommy.Reynolds at MegaCoder.com Thu Jan 5 17:59:06 2006 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Thu, 5 Jan 2006 11:59:06 -0600 Subject: edit root alias when installing the OS In-Reply-To: <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> Message-ID: <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> Uttered n0dalus , spake thus: > I know other distributions do this, but I don't think it is a good > idea. Adding the first user to /etc/sudoers means that any malware > only needs to get that user's password, or get itself to run after you > use sudo, and then it gets root access. > > I don't see what is wrong with using su. 1) Once any non-admin learns the root password, everybody knows the root password. And unless the admin wants to do every trivial admin activity, the root password must be given out and thus compromized. 2) Root logins are security problems because you can't tell which human actually logged on in the guise of root. Whom do you fire, even if you figure out what was done? 3) Sudo(1) allows fine control over which programs a user can run as any other user. 4) With sudo(1), an authenticated user must reauthenticate to run a program as another user. (Trusted users need not reauthenticate.) 5) Sudo(1) logs the activity so you will have an audit trail. System console, and syslog. Using sudo(1) is a big security win. Unfortunately, the man(1) page is a bit confusing for newbies and using su(8) seems so convenient. But with a small setup step, I can safely allow: $ sudo rpm -Uvh /path/to/a/package to be run by a trusted user because I'll get notices about it the attempt, its success or failure, as well as getting a record about what command line was used. HTH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seandarcy2 at gmail.com Thu Jan 5 18:10:54 2006 From: seandarcy2 at gmail.com (sean) Date: Thu, 05 Jan 2006 13:10:54 -0500 Subject: yum update gone bad today? Message-ID: yum has worked for months. It worked yesterday. Now: yum update Repository development is listed more than once in the configuration Setting up Update Process Setting up repositories http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/repodata/repomd.xml: [Errno 4] IOError: Trying other mirror. Cannot open/read repomd.xml file for repository: development failure: repodata/repomd.xml from development: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from development: [Errno 256] No more mirrors to try. Tried yum-2.5.0-5 and yum-2.4.1-3. Same result. cat yum.conf [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=fedora-release tolerant=1 exactarch=0 retries=20 [development] name=Fedora Core $releasever - Development Tree baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64 mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide enabled=1 I can pull up http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/repodata/repomd.xml in firefox. And it doesn't seem to try the mirrors. Something changed about yum configuration I've missed? Any one else seing this? sean From sundaram at redhat.com Thu Jan 5 18:14:46 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 05 Jan 2006 23:44:46 +0530 Subject: edit root alias when installing the OS In-Reply-To: <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> Message-ID: <43BD6216.4090206@redhat.com> Hi >1) Once any non-admin learns the root password, everybody knows the root >password. And unless the admin wants to do every trivial admin >activity, the root password must be given out and thus compromized. > >2) Root logins are security problems because you can't tell which >human actually logged on in the guise of root. Whom do you fire, >even if you figure out what was done? > >3) Sudo(1) allows fine control over which programs a user can run as >any other user. > >4) With sudo(1), an authenticated user must reauthenticate to run a >program as another user. (Trusted users need not reauthenticate.) > >5) Sudo(1) logs the activity so you will have an audit trail. System >console, and syslog. > > >Using sudo(1) is a big security win. > In many cases, yes it can be a big security win but the question here is do you want to the default user to have all administrative access through his own password?. That makes sense for the typical home user who owns his system anyway but it doesnt seem to be a big advantage for any system where system administration is done by other people who want to limit access to only non-root routine tasks for regular users. Several programs might not work well with sudo like webmin for instance. Shell redirection under sudo might not well as expected. ex: sudo ls /etc > /root/etc.list. If we decide that Fedora Core will be squarely targeted at the desktop then sudo might work well but otherwise I dont see it as a generic default solution. From orion at cora.nwra.com Thu Jan 5 18:59:41 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 05 Jan 2006 11:59:41 -0700 Subject: Replacing LAM with OpenMPI in Fedora Core In-Reply-To: <1136226300.30006.345.camel@ernie> References: <1136226300.30006.345.camel@ernie> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ed Hill wrote: > > I understand that OpenMPI is supposed to [at least, for some people's > perception! ;-)] become the "one true MPI" implementation that eclipses > all others due to its very cool new modular design and other features. > But, even so, I think it would be a good idea to have and maintain other > MPI versions (such as MPICH v1 & v2, LAM, etc.) in Extras so that people > have some flexibility. And to do that, we'll very likely need to setup > the multiple MPI packages using alternatives. While we are thinking about this, it would be good to be able to support multiple versions of a particular MPI compiled with different compilers. Locally I maintain LAM compiled with PGF90 and IFORT and it would be nice to be able to have all three installed simultaneously. - - Orion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDvWycORnzrtFC2/sRAqV4AJ0XmKYeeGFHXgLR0YOKh307a08cTwCfTNEm b2XWFDI9BgSzqsIvcOvICHk= =lUth -----END PGP SIGNATURE----- From johnp at redhat.com Thu Jan 5 19:18:37 2006 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 05 Jan 2006 14:18:37 -0500 Subject: CD Eject In-Reply-To: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> Message-ID: <1136488717.22333.42.camel@remedyz.boston.redhat.com> On Thu, 2006-01-05 at 14:04 +0000, Joe Desbonnet wrote: > I know it's not the unix way, but is there any reason why this can't > be done? There is no Unix way only the way which is best for the user. > .. given that USB stick drives can be yanked out without the > machine exploding, why not CD/DVDs? First, never yank a mounted USB device. You can't do this on any OS without possibly causing serious data loss. Because flash drives are really slow and constantly writing to them can wear them out faster, data is queued up and synced to device at regular intervals. Yanking it before a write can finish will damage the drive. As for drives opening I would guess we could listen for the button press and do an unmount/eject. The question is do we get eject button signals from the kernel. -- John (J5) Palmieri From sundaram at redhat.com Thu Jan 5 19:23:53 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 06 Jan 2006 00:53:53 +0530 Subject: CD Eject In-Reply-To: <43BD2EDA.9070601@gmail.com> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> <43BD2EDA.9070601@gmail.com> Message-ID: <43BD7249.3040508@redhat.com> Yuri Prushinsky wrote: > Joe, seems that supermount patch for linux kernel was designed for > this purpose and was implemented in Mandrake linux distros > You are talking about supermount or supermount-ng which isnt getting upstreamed. The better way might using non hackish stuff like HAL and dbus. From sundaram at redhat.com Thu Jan 5 19:26:25 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 06 Jan 2006 00:56:25 +0530 Subject: CD Eject In-Reply-To: <1136488717.22333.42.camel@remedyz.boston.redhat.com> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> <1136488717.22333.42.camel@remedyz.boston.redhat.com> Message-ID: <43BD72E1.2090008@redhat.com> Hi >First, never yank a mounted USB device. You can't do this on any OS >without possibly causing serious data loss. Because flash drives are >really slow and constantly writing to them can wear them out faster, >data is queued up and synced to device at regular intervals. Yanking it >before a write can finish will damage the drive. > > Right which is why Windows has a system tray message that says says remove devices or something similar. Might consider adopting a similar strategy of informing the user using libnotify and friends. >As for drives opening I would guess we could listen for the button press >and do an unmount/eject. The question is do we get eject button signals >from the kernel. > > This has been a often requested feature which has been dumbed down so far as not being the Unix way as if that really mattered on that desktop. From rdieter at math.unl.edu Thu Jan 5 19:34:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 05 Jan 2006 13:34:08 -0600 Subject: Fedora Trademark Guidelines page awol Message-ID: The link on http://fedora.redhat.com/About/legal/trademarks/ to "Fedora Trademark Guidelines" http://fedora.redhat.com/About/legal/trademarks/guidelines/ seems dead. Anyone have a better/working link? -- Rex From sundaram at redhat.com Thu Jan 5 19:37:33 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 06 Jan 2006 01:07:33 +0530 Subject: Fedora Trademark Guidelines page awol In-Reply-To: References: Message-ID: <43BD757D.1010009@redhat.com> Rex Dieter wrote: > The link on > http://fedora.redhat.com/About/legal/trademarks/ > to "Fedora Trademark Guidelines" > http://fedora.redhat.com/About/legal/trademarks/guidelines/ > > seems dead. Anyone have a better/working link? > > -- Rex http://fedora.redhat.com/About/legal/. Please file bug reports on missing links against fedora infrastructure in bugzilla so that it can be redirected as appropriate. From naheemzaffar at gmail.com Thu Jan 5 19:30:59 2006 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Thu, 5 Jan 2006 19:30:59 +0000 Subject: edit root alias when installing the OS In-Reply-To: <43BD6216.4090206@redhat.com> References: <1136149140.3230.5.camel@rivendell.home.local> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <43BD6216.4090206@redhat.com> Message-ID: <3adc77210601051130h381ba9aao6cb36f3ca3abd964@mail.gmail.com> I believe adding the primary user to sudo should be an option on firstboot. As a newbie it is almost scary adding your name to the sudoers file, and is abit of guesswork. And you have to know it exists. Its less scary to just use root. Firstboot should give a tickbox option to add the primary user to sudo (ticked by default for 'desktop' installs, and unticked by default for other install types if possible...) which type of sudo? I did not even know there were types! just choose the most secure option as default. Whatever that is. Powerusers can change it the old way if needed. (there shouldalso be an option for this in users and groups package in the in the menu menu) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Thu Jan 5 19:43:53 2006 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 05 Jan 2006 19:43:53 +0000 Subject: CD Eject In-Reply-To: <1136488717.22333.42.camel@remedyz.boston.redhat.com> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> <1136488717.22333.42.camel@remedyz.boston.redhat.com> Message-ID: <1136490233.28143.1.camel@localhost> On Thu, 2006-01-05 at 14:18 -0500, John (J5) Palmieri wrote: > As for drives opening I would guess we could listen for the button press > and do an unmount/eject. The question is do we get eject button signals > from the kernel. Kay's already done this in HAL (for supported drives): http://lists.freedesktop.org/archives/hal/2005-October/003679.html I guess it has to be hooked up to g-v-m or something. Richard. From pemboa at gmail.com Thu Jan 5 19:48:02 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 5 Jan 2006 13:48:02 -0600 Subject: edit root alias when installing the OS In-Reply-To: <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> Message-ID: <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> On 1/5/06, Tommy Reynolds wrote: > > Uttered n0dalus , spake thus: > > > I know other distributions do this, but I don't think it is a good > > idea. Adding the first user to /etc/sudoers means that any malware > > only needs to get that user's password, or get itself to run after you > > use sudo, and then it gets root access. > > > > I don't see what is wrong with using su. > > 1) Once any non-admin learns the root password, everybody knows the root > password. And unless the admin wants to do every trivial admin > activity, the root password must be given out and thus compromized. > > 2) Root logins are security problems because you can't tell which > human actually logged on in the guise of root. Whom do you fire, > even if you figure out what was done? > > 3) Sudo(1) allows fine control over which programs a user can run as > any other user. > > 4) With sudo(1), an authenticated user must reauthenticate to run a > program as another user. (Trusted users need not reauthenticate.) > > 5) Sudo(1) logs the activity so you will have an audit trail. System > console, and syslog. > > > Using sudo(1) is a big security win. Unfortunately, the man(1) page > is a bit confusing for newbies and using su(8) seems so convenient. > But with a small setup step, I can safely allow: > > $ sudo rpm -Uvh /path/to/a/package > > to be run by a trusted user because I'll get notices about it the > attempt, its success or failure, as well as getting a record about > what command line was used. > > HTH > > Seems to me that there is a need for a system-config-sudo from someone who understands it all. I am ashamed to say that I have very little about it. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdieter at math.unl.edu Thu Jan 5 19:49:25 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 05 Jan 2006 13:49:25 -0600 Subject: Fedora Trademark Guidelines page awol In-Reply-To: <43BD757D.1010009@redhat.com> References: <43BD757D.1010009@redhat.com> Message-ID: <43BD7845.4020703@math.unl.edu> Rahul Sundaram wrote: > Rex Dieter wrote: > >> The link on >> http://fedora.redhat.com/About/legal/trademarks/ >> to "Fedora Trademark Guidelines" >> http://fedora.redhat.com/About/legal/trademarks/guidelines/ >> >> seems dead. Anyone have a better/working link? > http://fedora.redhat.com/About/legal/. Please file bug reports on > missing links against fedora infrastructure in bugzilla so that it can > be redirected as appropriate. done, http://bugzilla.redhat.com/bugzilla/177053 -- Rex From hughsient at gmail.com Thu Jan 5 19:54:00 2006 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 05 Jan 2006 19:54:00 +0000 Subject: edit root alias when installing the OS In-Reply-To: <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> Message-ID: <1136490840.28143.3.camel@localhost> On Thu, 2006-01-05 at 13:48 -0600, Arthur Pemberton wrote: > On 1/5/06, Tommy Reynolds wrote: > Seems to me that there is a need for a system-config-sudo from someone > who understands it all. I am ashamed to say that I have very little > about it. Agreed, a graphical tool would make it very easy to configure. Any python hackers bored? Richard. From sundaram at redhat.com Thu Jan 5 19:55:20 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 06 Jan 2006 01:25:20 +0530 Subject: edit root alias when installing the OS In-Reply-To: <1136490840.28143.3.camel@localhost> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> <1136490840.28143.3.camel@localhost> Message-ID: <43BD79A8.8070802@redhat.com> Richard Hughes wrote: >On Thu, 2006-01-05 at 13:48 -0600, Arthur Pemberton wrote: > > >>On 1/5/06, Tommy Reynolds wrote: >>Seems to me that there is a need for a system-config-sudo from someone >>who understands it all. I am ashamed to say that I have very little >>about it. >> >> > >Agreed, a graphical tool would make it very easy to configure. Any >python hackers bored? > > Wouldnt it make sense to add this functionality to system-config-users rather than creating yet another tool? From sundaram at redhat.com Thu Jan 5 19:58:00 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 06 Jan 2006 01:28:00 +0530 Subject: Comments in configuration files In-Reply-To: <1136490793.2805.21.camel@localhost.localdomain> References: <43BD1C87.4060504@redhat.com> <1136490793.2805.21.camel@localhost.localdomain> Message-ID: <43BD7A48.2090300@redhat.com> Stuart Ellis wrote: >On Thu, 2006-01-05 at 18:47 +0530, Rahul Sundaram wrote: > > >>Hi >> >>It seems that several configuration files in Fedora does not include >>helpful comments as necessary to guide users on where to look for >>information or which formats to follow. The crontab files could have a >>initial commented line specifying the format or hosts file could refer >>people to its man page for examples. Would the documentation team be >>willing to file bug reports with comments/content as appropriate? >> >>Do we need such guidelines as inclusion/release criteria? >> >> > >I think that it would be a good policy for those configuration files >that are written by Red Hat or Fedora developers >(e.g. /etc/sysconfig/*, /etc/httpd/conf.d/*), even if it's just a bit of >boilerplate text that identifies the file as a custom item and provides >a reference for more information. > >Where configuration files are supplied by upstream as part of the >software, it may be that tweaking them would be felt to be against the >general use-upstream-defaults policy. That's probably something that >would need discussion on development or maintainer lists to work out. > > (CCing fedora-devel list) Might patch these as appropriate and send these upstream as required if agreed upon as a general policy. From ed at eh3.com Thu Jan 5 19:57:57 2006 From: ed at eh3.com (Ed Hill) Date: Thu, 05 Jan 2006 14:57:57 -0500 Subject: Replacing LAM with OpenMPI in Fedora Core In-Reply-To: References: <1136226300.30006.345.camel@ernie> Message-ID: <1136491078.20505.115.camel@ernie> On Thu, 2006-01-05 at 11:59 -0700, Orion Poplawski wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ed Hill wrote: > > > > I understand that OpenMPI is supposed to [at least, for some people's > > perception! ;-)] become the "one true MPI" implementation that eclipses > > all others due to its very cool new modular design and other features. > > But, even so, I think it would be a good idea to have and maintain other > > MPI versions (such as MPICH v1 & v2, LAM, etc.) in Extras so that people > > have some flexibility. And to do that, we'll very likely need to setup > > the multiple MPI packages using alternatives. > > While we are thinking about this, it would be good to be able to support > multiple versions of a particular MPI compiled with different compilers. > Locally I maintain LAM compiled with PGF90 and IFORT and it would be > nice to be able to have all three installed simultaneously. Hi Orion, Yes, we also have groups of machines where we maintain combinations of compilers, MPI libs, etc.: MPI: LAM, mpich, mpich-vmi, etc. Compilers: GNU (multiple versions), Intel, PGI, etc. and we do it with an install framework that looks something like: /opt/pkg/${PKG_NAME} and/or /usr/local/pkg/${PKG_NAME} and then let users dynamically chose which packages or combinations of packages to use with the environment modules scripts: http://modules.sourceforge.net/ I like the above setup because: + its quite flexible and can handle dependencies between the packages pretty gracefully + it can be made to work (play nicely!) with the in-Core MPI setup and/or any number of additional MPI setups which might be installed (perhas someday?) through Fedora Extras or local installs + its an increasingly popular arrangement for scientific and high-performance computing systems I'd like to see as much of the above as possible included in Fedora Extras and [given what little free time I have! :-)] I'm doing what I can to try and get the necessary parts packaged, etc. I have a modules package in progress and will be glad to share my unfinished bits with anyone who is interested. Do you have any objections to the above or maybe suggestions for improvements? Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From seg at haxxed.com Thu Jan 5 20:11:17 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 05 Jan 2006 14:11:17 -0600 Subject: edit root alias when installing the OS In-Reply-To: <1136443885.9226.13.camel@locolhost.localdomain> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> Message-ID: <1136491878.20011.14.camel@localhost> Personally I wouldn't mind seeing Fedora move to a no root login system, like OSX and (apparently) Ubuntu have. Eliminate the root password entirely. One thing I really want to see is for usermode to just be replaced with sudo. I'm confused as to why usermode was created rather than just using a sudo policy. Then you could run system configuration tools by using your own login password (OSX style) rather than the root password. From nicolas.mailhot at laposte.net Thu Jan 5 20:09:18 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 05 Jan 2006 21:09:18 +0100 Subject: Comments in configuration files In-Reply-To: <43BD7A48.2090300@redhat.com> References: <43BD1C87.4060504@redhat.com> <1136490793.2805.21.camel@localhost.localdomain> <43BD7A48.2090300@redhat.com> Message-ID: <43BD7CEE.1060303@laposte.net> Rahul Sundaram wrote: > Stuart Ellis wrote: > >> On Thu, 2006-01-05 at 18:47 +0530, Rahul Sundaram wrote: >> >> >>> Hi >>> >>> It seems that several configuration files in Fedora does not include >>> helpful comments as necessary to guide users on where to look for >>> information or which formats to follow. The crontab files could have >>> a initial commented line specifying the format or hosts file could >>> refer people to its man page for examples. Would the documentation >>> team be willing to file bug reports with comments/content as >>> appropriate? >>> >>> Do we need such guidelines as inclusion/release criteria? >>> >> >> I think that it would be a good policy for those configuration files >> that are written by Red Hat or Fedora developers >> (e.g. /etc/sysconfig/*, /etc/httpd/conf.d/*), even if it's just a bit of >> boilerplate text that identifies the file as a custom item and provides >> a reference for more information. >> >> Where configuration files are supplied by upstream as part of the >> software, it may be that tweaking them would be felt to be against the >> general use-upstream-defaults policy. That's probably something that >> would need discussion on development or maintainer lists to work out. >> >> > (CCing fedora-devel list) > Might patch these as appropriate and send these upstream as required if > agreed upon as a general policy. +1 a textbook case is /etc/cpuspeed.conf The shipped conf file is the only "documentation" of the package. The various options are not documented anywhere else. And the comments in the conf file itself are somehow lacking Regards, -- Nicolas Mailhot From mhoneyfield at gmail.com Thu Jan 5 20:16:18 2006 From: mhoneyfield at gmail.com (Michael Honeyfield) Date: Fri, 6 Jan 2006 09:16:18 +1300 Subject: edit root alias when installing the OS In-Reply-To: <1136491878.20011.14.camel@localhost> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> Message-ID: <37f97dbd0601051216j760ba93dh875ee78f7edd95d6@mail.gmail.com> On 1/6/06, Callum Lerwick wrote: > Personally I wouldn't mind seeing Fedora move to a no root login system, > like OSX and (apparently) Ubuntu have. Eliminate the root password > entirely. > > One thing I really want to see is for usermode to just be replaced with > sudo. I'm confused as to why usermode was created rather than just using > a sudo policy. Then you could run system configuration tools by using > your own login password (OSX style) rather than the root password. > This is nothing new, many distros have been doing this for a long time. disabling the root account or disabling root login via gdm/kdm. Michael From seg at haxxed.com Thu Jan 5 20:31:08 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 05 Jan 2006 14:31:08 -0600 Subject: edit root alias when installing the OS In-Reply-To: <37f97dbd0601051216j760ba93dh875ee78f7edd95d6@mail.gmail.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <37f97dbd0601051216j760ba93dh875ee78f7edd95d6@mail.gmail.com> Message-ID: <1136493068.20011.18.camel@localhost> On Fri, 2006-01-06 at 09:16 +1300, Michael Honeyfield wrote: > This is nothing new, many distros have been doing this for a long > time. disabling the root account or disabling root login via gdm/kdm. This doesn't work with usermode for one, it depends on the root password near as I can tell. Its also a problem if say fsck fails during boot and you're dropped to a single user shell. You're prompted for the root password. How does Ubuntu handle that one? From sundaram at redhat.com Thu Jan 5 20:30:34 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 06 Jan 2006 02:00:34 +0530 Subject: edit root alias when installing the OS In-Reply-To: <1136493068.20011.18.camel@localhost> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <37f97dbd0601051216j760ba93dh875ee78f7edd95d6@mail.gmail.com> <1136493068.20011.18.camel@localhost> Message-ID: <43BD81EA.1030104@redhat.com> Callum Lerwick wrote: >On Fri, 2006-01-06 at 09:16 +1300, Michael Honeyfield wrote: > > >>This is nothing new, many distros have been doing this for a long >>time. disabling the root account or disabling root login via gdm/kdm. >> >> > >This doesn't work with usermode for one, it depends on the root password >near as I can tell. Its also a problem if say fsck fails during boot and >you're dropped to a single user shell. You're prompted for the root >password. How does Ubuntu handle that one? > > > They patch it. https://wiki.ubuntu.com/RootSudo From tadams-lists at myrealbox.com Thu Jan 5 20:35:57 2006 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Thu, 05 Jan 2006 13:35:57 -0700 Subject: yum update gone bad today? In-Reply-To: References: Message-ID: <1136493357.2462.8.camel@aurora.localdomain> I had this happen on one machine. Make sure you remove all nisplus entries from any line that is not commented (#) in /etc/nsswitch.conf. Note, you do not remove the entire line, you just remove nisplus. I had one computer that had this problem and this is what fixed it. IT was also very interesting. None of the other machines have nisplus entries. I do not know why one would get it (that was only occassionally updated) while another didn't and none of the ones that get updated nearly every day had the problem. Trever Adams On Thu, 2006-01-05 at 13:10 -0500, sean wrote: > yum has worked for months. It worked yesterday. Now: > > yum update > Repository development is listed more than once in the > configuration > Setting up Update Process > Setting up repositories > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/repodata/repomd.xml: > [Errno 4] IOError: directory')> > Trying other mirror. > Cannot open/read repomd.xml file for repository: development > failure: repodata/repomd.xml from development: [Errno 256] > No more mirrors to try. > Error: failure: repodata/repomd.xml from development: [Errno > 256] No more mirrors to try. > > > Tried yum-2.5.0-5 and yum-2.4.1-3. Same result. > > cat yum.conf > [main] > cachedir=/var/cache/yum > debuglevel=2 > logfile=/var/log/yum.log > pkgpolicy=newest > distroverpkg=fedora-release > tolerant=1 > exactarch=0 > retries=20 > > [development] > name=Fedora Core $releasever - Development Tree > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64 > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide > enabled=1 > > > I can pull up > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/repodata/repomd.xml > in firefox. > > And it doesn't seem to try the mirrors. > > Something changed about yum configuration I've missed? > > Any one else seing this? > > sean > -- "I don't know how World War III will be fought, but I do know World War IV will be fought with sticks and stones" -- Einstein From gajownik at fedora.pl Thu Jan 5 20:53:49 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 05 Jan 2006 21:53:49 +0100 Subject: CD Eject In-Reply-To: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> Message-ID: <43BD875D.8010005@fedora.pl> Dnia 01/05/2006 03:04 PM, U?ytkownik Joe Desbonnet napisa?: > You press the CD Eject button and the CD ejects (always!) You can always do: echo 0 > /proc/sys/dev/cdrom/lock to disable locking. It's really helpful when you mount scratched CDs ;) -- ^_* From seandarcy2 at gmail.com Thu Jan 5 21:55:38 2006 From: seandarcy2 at gmail.com (sean) Date: Thu, 05 Jan 2006 16:55:38 -0500 Subject: yum update gone bad today? In-Reply-To: <1136493357.2462.8.camel@aurora.localdomain> References: <1136493357.2462.8.camel@aurora.localdomain> Message-ID: Wow! Who woulda guesssed? You're 2006's fedora man of the year ( so far). Thanks. sean Trever L. Adams wrote: > I had this happen on one machine. Make sure you remove all nisplus > entries from any line that is not commented (#) in /etc/nsswitch.conf. > Note, you do not remove the entire line, you just remove nisplus. > > I had one computer that had this problem and this is what fixed it. IT > was also very interesting. None of the other machines have nisplus > entries. I do not know why one would get it (that was only occassionally > updated) while another didn't and none of the ones that get updated > nearly every day had the problem. > > Trever Adams > > On Thu, 2006-01-05 at 13:10 -0500, sean wrote: > >>yum has worked for months. It worked yesterday. Now: >> >> yum update >>Repository development is listed more than once in the >>configuration >>Setting up Update Process >>Setting up repositories >>http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/repodata/repomd.xml: >>[Errno 4] IOError: >directory')> >>Trying other mirror. >>Cannot open/read repomd.xml file for repository: development >>failure: repodata/repomd.xml from development: [Errno 256] >>No more mirrors to try. >>Error: failure: repodata/repomd.xml from development: [Errno >>256] No more mirrors to try. >> >> >>Tried yum-2.5.0-5 and yum-2.4.1-3. Same result. >> >> cat yum.conf >>[main] >>cachedir=/var/cache/yum >>debuglevel=2 >>logfile=/var/log/yum.log >>pkgpolicy=newest >>distroverpkg=fedora-release >>tolerant=1 >>exactarch=0 >>retries=20 >> >>[development] >>name=Fedora Core $releasever - Development Tree >>baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64 >>mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide >>enabled=1 >> >> >>I can pull up >>http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/repodata/repomd.xml >>in firefox. >> >>And it doesn't seem to try the mirrors. >> >>Something changed about yum configuration I've missed? >> >>Any one else seing this? >> >>sean >> > > -- > "I don't know how World War III will be fought, but I do know World War > IV will be fought with sticks and stones" -- Einstein > From dravet at hotmail.com Thu Jan 5 21:59:25 2006 From: dravet at hotmail.com (Jason Dravet) Date: Thu, 05 Jan 2006 15:59:25 -0600 Subject: xorg 7 Message-ID: Currently rawhide has X Window System Version 6.99.99.904 (7.0.0 RC 4). With the test2 freeze only days away I was wondering if rawhide is going to get X11R7.0 for test2? Thanks, Jason From seg at haxxed.com Thu Jan 5 22:57:10 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 05 Jan 2006 16:57:10 -0600 Subject: edit root alias when installing the OS In-Reply-To: <43BD81EA.1030104@redhat.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <37f97dbd0601051216j760ba93dh875ee78f7edd95d6@mail.gmail.com> <1136493068.20011.18.camel@localhost> <43BD81EA.1030104@redhat.com> Message-ID: <1136501831.20011.22.camel@localhost> On Fri, 2006-01-06 at 02:00 +0530, Rahul Sundaram wrote: > Callum Lerwick wrote: > >This doesn't work with usermode for one, it depends on the root password > >near as I can tell. Its also a problem if say fsck fails during boot and > >you're dropped to a single user shell. You're prompted for the root > >password. How does Ubuntu handle that one? > > > They patch it. https://wiki.ubuntu.com/RootSudo Err, patch it to do what exactly? I've never tried Ubuntu. Does it just prompt for a username/password of an admin user instead? From mpeters at mac.com Fri Jan 6 03:07:13 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 05 Jan 2006 19:07:13 -0800 Subject: edit root alias when installing the OS In-Reply-To: <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> Message-ID: <1136516834.2899.15.camel@locolhost.localdomain> On Thu, 2006-01-05 at 11:59 -0600, Tommy Reynolds wrote: > Uttered n0dalus , spake thus: > > > I know other distributions do this, but I don't think it is a good > > idea. Adding the first user to /etc/sudoers means that any malware > > only needs to get that user's password, or get itself to run after you > > use sudo, and then it gets root access. > > > > I don't see what is wrong with using su. > > 1) Once any non-admin learns the root password, everybody knows the root > password. And unless the admin wants to do every trivial admin > activity, the root password must be given out and thus compromized. You do not give the root password out to those who should not have it. Very simple. Giving sudo access to a shell is just as bad as giving out the root password. > > 2) Root logins are security problems because you can't tell which > human actually logged on in the guise of root. Whom do you fire, > even if you figure out what was done? That's rarely an issue - accounting does keep track of who used su to obtain root. remote root login should never be allowed, it should require an su - or login from the console, which can be access restricted. > > 3) Sudo(1) allows fine control over which programs a user can run as > any other user. Yes - and it is a useful tool when it is properly administered. That means you don't set up a weak default like OS X and some Linux distributions do. > > 4) With sudo(1), an authenticated user must reauthenticate to run a > program as another user. (Trusted users need not reauthenticate.) > > 5) Sudo(1) logs the activity so you will have an audit trail. System > console, and syslog. Which can easily be modified (unless you are using a properly secured log server) if sudo can spawn a shell. > > > Using sudo(1) is a big security win. In some cases, properly administered by someone who understands sudo and the implications of sudo. > Unfortunately, the man(1) page > is a bit confusing for newbies and using su(8) seems so convenient. > But with a small setup step, I can safely allow: > > $ sudo rpm -Uvh /path/to/a/package > > to be run by a trusted user because I'll get notices about it the > attempt, its success or failure, as well as getting a record about > what command line was used. I would never allow sudo to use an rpm. An rpm sciptlet can do a lot of damage. I might allow sudo to invoke yum - with signature checking, so that a user could use yum localinstall - in which case packages not signed by trusted GPG key would fail. The options that could be passes to yum would have to be very limited though. From mpeters at mac.com Fri Jan 6 03:15:05 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 05 Jan 2006 19:15:05 -0800 Subject: edit root alias when installing the OS In-Reply-To: <1136491878.20011.14.camel@localhost> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> Message-ID: <1136517305.2899.19.camel@locolhost.localdomain> On Thu, 2006-01-05 at 14:11 -0600, Callum Lerwick wrote: > Personally I wouldn't mind seeing Fedora move to a no root login system, > like OSX and (apparently) Ubuntu have. Eliminate the root password > entirely. I can't speak for Ubuntu - but OS X has a root account. sudo su - and you are root. It weakens OS X because by default, every admin password is essentially a root password. OS X gives too much to the admin accounts - why do you think repairing permissions is such a common thing on OS X? In the early days it was *really* bad - as one could from a local account do nidump passwd . and then run it through jtr to crack weak admin passwords (and thus root the box). At least now they finally have some sort of shadow implemented to prevent that. From n0dalus+redhat at gmail.com Fri Jan 6 03:33:38 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Fri, 6 Jan 2006 14:03:38 +1030 Subject: edit root alias when installing the OS In-Reply-To: <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> Message-ID: <6280325c0601051933o62b822f2t187b95cbf2b45cfd@mail.gmail.com> On 1/6/06, Tommy Reynolds wrote: > > 1) Once any non-admin learns the root password, everybody knows the root > password. And unless the admin wants to do every trivial admin > activity, the root password must be given out and thus compromized. > > 2) Root logins are security problems because you can't tell which > human actually logged on in the guise of root. Whom do you fire, > even if you figure out what was done? > > 3) Sudo(1) allows fine control over which programs a user can run as > any other user. I agree that for multi-admin systems sudo is useful. > 4) With sudo(1), an authenticated user must reauthenticate to run a > program as another user. (Trusted users need not reauthenticate.) > > 5) Sudo(1) logs the activity so you will have an audit trail. System > console, and syslog. Unless you really lock down sudo, there are many ways to make a seemingly harmless command in the log be really devastating. For example, run `sudo ` and before you know it someone running the 'php' command has just done a whole lot of damage to the system. I am the only person who needs root access on my systems, so I don't really need to use sudo. I use Fedora as a desktop, and I would hate it if the root user was disabled by default (and you were forced to use sudo). Of course users shouldn't be logging in as root, but removing the idea of a root user entirely is just bad. Adding the first user to sudoers by default is only making the system insecure, and it weakens the unix concept of root. Before you know it every user will be in sudoers (just like every Windows user is an administrator) and the system will only be as safe as its weakest password. I think people can handle the concept of root just fine as it is. We should not be dumbing it down and weakening the security of the systems by default. I think the WinXP login screen is good with the way it doesn't show the 'Administrator' user unless you press a key-combination -- maybe gdm could do something similar and not let you login as root until you press something. Users need to be taught to respect the root account, not taught to think that every user should be able to perform system operations by putting in their password. n0dalus. From pemboa at gmail.com Fri Jan 6 04:18:40 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 5 Jan 2006 22:18:40 -0600 Subject: edit root alias when installing the OS In-Reply-To: <1136516834.2899.15.camel@locolhost.localdomain> References: <1136149140.3230.5.camel@rivendell.home.local> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <1136516834.2899.15.camel@locolhost.localdomain> Message-ID: <16de708d0601052018q23d9a167vb86bdeb1a495263@mail.gmail.com> On 1/5/06, Michael A. Peters wrote: [snip] > Yes - and it is a useful tool when it is properly administered. > That means you don't set up a weak default like OS X and some Linux > distributions do. > > Well then maybe we should take some time to discover a better default for Fedora. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpeters at mac.com Fri Jan 6 07:22:45 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 05 Jan 2006 23:22:45 -0800 Subject: edit root alias when installing the OS In-Reply-To: <16de708d0601052018q23d9a167vb86bdeb1a495263@mail.gmail.com> References: <1136149140.3230.5.camel@rivendell.home.local> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <1136516834.2899.15.camel@locolhost.localdomain> <16de708d0601052018q23d9a167vb86bdeb1a495263@mail.gmail.com> Message-ID: <1136532165.2899.23.camel@locolhost.localdomain> On Thu, 2006-01-05 at 22:18 -0600, Arthur Pemberton wrote: > > > On 1/5/06, Michael A. Peters wrote: > [snip] > Yes - and it is a useful tool when it is properly > administered. > That means you don't set up a weak default like OS X and some > Linux > distributions do. > > Well then maybe we should take some time to discover a better default > for Fedora. No - I think a better thing to do is make sure that graphical tools exist - and *maybe* create a wheel group so that when a user in that group is the pam console user, they don't need any further authentication to run the graphical tools. I believe the facilities to do that already exist. From naoki at valuecommerce.com Fri Jan 6 07:53:07 2006 From: naoki at valuecommerce.com (Naoki) Date: Fri, 06 Jan 2006 16:53:07 +0900 Subject: xorg 7 In-Reply-To: References: Message-ID: <1136533987.3626.81.camel@dragon.sys.intra> 7.0 is officially released now. There was a move to modular X a couple ( few? ) weeks back so it certainly looks like it'll be shipping with 7.0 On Thu, 2006-01-05 at 15:59 -0600, Jason Dravet wrote: > Currently rawhide has X Window System Version 6.99.99.904 (7.0.0 RC 4). > With the test2 freeze only days away I was wondering if rawhide is going to > get X11R7.0 for test2? > > Thanks, > Jason > From buildsys at redhat.com Fri Jan 6 10:16:52 2006 From: buildsys at redhat.com (Build System) Date: Fri, 6 Jan 2006 05:16:52 -0500 Subject: rawhide report: 20060106 changes Message-ID: <200601061016.k06AGqLC010992@porkchop.devel.redhat.com> New package libgpod Library to access the contents of an iPod Updated Packages: audit-1.1.3-1 ------------- * Thu Jan 05 2006 Steve Grubb 1.1.3-1 - Add timestamp to daemon_config messages (#174865) - Add error checking of year for aureport & ausearh - Treat af_unix sockets as files for searching and reporting - Update capp & lspp rules to combine syscalls for higher performance - Adjusted the chkconfig line for auditd to start a little earlier - Added skeleton program to docs for people to write their own dispatcher with - Apply patch from Ulrich Drepper that optimizes resource utilization - Change ausearch and aureport to unlocked IO * Mon Dec 05 2005 Steve Grubb 1.1.2-1 - Add more message types * Wed Nov 30 2005 Steve Grubb 1.1.1-1 - Add support for alpha processors - Update the audisp code - Add locale code in ausearch and aureport - Add new rule operator patch - Add exclude filter patch - Cleanup make files - Add python bindings boost-1.33.1-4 -------------- * Thu Jan 05 2006 Benjamin Kosnik 1.33.1-4 - Fix symbolic links. cadaver-0.22.3-1 ---------------- * Fri Jan 06 2006 Joe Orton 0.22.3-1 - update to 0.22.3 checkpolicy-1.28-4 ------------------ * Thu Jan 05 2006 Dan Walsh 1.28-4 - Rebuild to get latest libsepol evolution-data-server-1.5.4-2 ----------------------------- * Thu Jan 05 2006 David Malcolm - 1.5.4-2 - added patch from David Woodhouse to validate reverse DNS domain before using in SMTP greeting (patch 103, #151121) glibc-2.3.90-27 --------------- * Fri Jan 06 2006 Jakub Jelinek 2.3.90-27 - only rely on d_type in 32-bit getdents on s390 for 2.6.11+ gnome-applets-1:2.13.1-4 ------------------------ * Thu Jan 05 2006 John (J5) Palmieri 2.13.1-4 - GStreamer has been split into gstreamer08 and gstreamer (0.10) packages we need gstreamer08 for now gnome-panel-2.13.4-1 -------------------- * Thu Jan 05 2006 Matthias Clasen 2.13.4-1 - Update to 2.13.4 - reinstate the desktop-menu-renaming gnome-python2-extras-2.12.1-9 ----------------------------- * Thu Jan 05 2006 John (J5) Palmieri - 2.12.1-9 - Last rebuild didn't get the new libgtop gnome-terminal-2.13.0-2 ----------------------- * Wed Jan 04 2006 Christopher Aillon 2.13.0-2 - Revert patch from gnome bug 98715 to fix 176029, 176642 hal-0.5.5.1.cvs20060105-2 ------------------------- * Thu Jan 05 2006 John (J5) Palmieri - 0.5.5.1.cvs20060105-1 - readd the hotplug script * Thu Jan 05 2006 John (J5) Palmieri - 0.5.5.1.cvs20060105-1 - Build CVS version of HAL which gives us the new mount support - disable fstab-sync - scripts have been moved from /usr/sbin to /usr/share/hal/scripts libsemanage-1.5.8-1 ------------------- * Fri Jan 06 2006 Dan Walsh 1.5.8-1 - Upgrade to latest from NSA * Re-applied string and file optimization patch from Russell Coker, with bug fix. * Reverted string and file optimization patch from Russell Coker. * Clarified error messages from parse_module_headers and parse_base_headers for base/module mismatches. * Fri Jan 06 2006 Dan Walsh 1.5.6-1 - Upgrade to latest from NSA * Clarified error messages from parse_module_headers and parse_base_headers for base/module mismatches. * Merged string and file optimization patch from Russell Coker. * Merged swig header reordering patch from Ivan Gyurdiev. * Merged toggle modify on add patch from Ivan Gyurdiev. * Merged ports parser bugfix patch from Ivan Gyurdiev. * Merged fcontext swig patch from Ivan Gyurdiev. * Merged remove add/modify/delete for active booleans patch from Ivan Gyurdiev. * Merged man pages for dbase functions patch from Ivan Gyurdiev. * Merged pywrap tests patch from Ivan Gyurdiev. * Thu Jan 05 2006 Dan Walsh 1.5.4-2 - Patch to fix add libsepol-1.11.5-1 ----------------- * Thu Jan 05 2006 Dan Walsh 1.11.5-1 - Upgrade to latest from NSA * Merged further fixes from Russell Coker, specifically: - av_to_string overflow checking - sepol_context_to_string error handling - hierarchy checking memory leak fixes and optimizations - avrule_block_read variable initialization * Marked deprecated code in genbools and genusers. nspr-4.6.1-2 ------------ * Thu Jan 05 2006 Kai Engert 4.6.1-2 - Do not use -ansi when compiling, because of a compilation problem with latest glibc and anonymous unions. See also bugzilla.mozilla.org # 322427. * Wed Jan 04 2006 Kai Engert - Add an upstream patch to fix gcc visibility issues. * Tue Jan 03 2006 Christopher Aillon - Stop shipping static libraries; NSS and dependencies no longer require static libraries to build. policycoreutils-1.29.5-1 ------------------------ * Thu Jan 05 2006 Dan Walsh 1.29.5-1 - Update to match NSA * Added filename to semodule error reporting. * Thu Jan 05 2006 Dan Walsh 1.29.4-1 - Update to match NSA * Merged genhomedircon and semanage patch from Dan Walsh. * Changed semodule error reporting to include argv[0]. python-pyblock-0.11-1 --------------------- * Thu Jan 05 2006 Peter Jones - 0.11-1 - never trust dmraid on sync vs nosync; right now, always transform the table to "default" (no argument), which is to sync only when necessary, whatever that means. Seems to lock up less often. sound-juicer-2.13.1-3 --------------------- * Thu Jan 05 2006 John (J5) Palmieir 2.13.1-3 - GStreamer has been split into gstreamer08 and gstreamer (0.10) packages we need gstreamer08 for now totem-1.3.0-2 ------------- * Thu Jan 05 2006 John (J5) Palmieri 1.3.0-2 - GStreamer has been split into gstreamer08 and gstreamer (0.10) packages we need gstreamer08 for now Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5smp jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 libofx - 0.8.0-1.i386 requires libosp.so.4 openhpi - 2.2.1-1.i386 requires libnetsnmp.so.9 openjade - 1.3.2-22.i386 requires libosp.so.4 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) libofx - 0.8.0-1.ia64 requires libosp.so.4()(64bit) openjade - 1.3.2-22.ia64 requires libosp.so.4()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 libofx - 0.8.0-1.ppc requires libosp.so.4 openhpi - 2.2.1-1.ppc requires libnetsnmp.so.9 openjade - 1.3.2-22.ppc requires libosp.so.4 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) libofx - 0.8.0-1.ppc64 requires libosp.so.4()(64bit) openhpi - 2.2.1-1.ppc64 requires libnetsnmp.so.9()(64bit) openjade - 1.3.2-22.ppc64 requires libosp.so.4()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 libofx - 0.8.0-1.s390 requires libosp.so.4 openhpi - 2.2.1-1.s390 requires libnetsnmp.so.9 openjade - 1.3.2-22.s390 requires libosp.so.4 Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libofx - 0.8.0-1.s390x requires libosp.so.4()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) openhpi - 2.2.1-1.s390x requires libnetsnmp.so.9()(64bit) openjade - 1.3.2-22.s390x requires libosp.so.4()(64bit) openjade - 1.3.2-22.s390 requires libosp.so.4 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) libofx - 0.8.0-1.x86_64 requires libosp.so.4()(64bit) openhpi - 2.2.1-1.x86_64 requires libnetsnmp.so.9()(64bit) openjade - 1.3.2-22.x86_64 requires libosp.so.4()(64bit) openjade - 1.3.2-22.i386 requires libosp.so.4 From camilo at mesias.co.uk Fri Jan 6 10:18:55 2006 From: camilo at mesias.co.uk (Cam) Date: Fri, 06 Jan 2006 10:18:55 +0000 Subject: USB storage question (was Re: CD Eject) In-Reply-To: <1136488717.22333.42.camel@remedyz.boston.redhat.com> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> <1136488717.22333.42.camel@remedyz.boston.redhat.com> Message-ID: <43BE440F.60900@mesias.co.uk> Hi > First, never yank a mounted USB device. Something that has been bothering me for a while, what is responsible for detecting and mounting USB devices on Fedora? The reason I ask is that I'd like to make sure that what I consider reasonable mount options are used, including noatime and shortname=win95 (I have a FAT based mp3 player that by default mounts but is unusable due to the default shortname setting) I would like to reconfigure it and if code changes are necessary to allow configurability then I might still be tempted. So please point me in the direction of something relevant... -Cam -- camilo at mesias.co.uk <-- From prushinsky at gmail.com Fri Jan 6 10:41:25 2006 From: prushinsky at gmail.com (Yuri Prushinsky) Date: Fri, 06 Jan 2006 13:41:25 +0300 Subject: glibc-2.3.90-26 and older kernels In-Reply-To: <1136478790.2509.4.camel@dhollis-lnx.sunera.com> References: <43BC69AC.1010601@redhat.com> <1136421529.6316.0.camel@yoda.jdub.homelinux.org> <43BC6B63.3070101@redhat.com> <1136427119.18235.30.camel@dragon.sys.intra> <1136478790.2509.4.camel@dhollis-lnx.sunera.com> Message-ID: <43BE4955.4070704@gmail.com> David, Fedora have different ideology than Gentoo or others, it's normal to require a version "not lower than" from the user if there's no other way to step ahead, it just should be specified in the release notes. Gnome vs KDE flame will burn only if the one will be removed from the core (something similar to what Patrick did with Slackware, I guess..) David Hollis wrote: > On Thu, 2006-01-05 at 11:11 +0900, Naoki wrote: > >>FC3 shipped with 2.6.9-1.667 by the way. So unless you're still booting >>with an FC2 kernel I can't see this change biting anybody. >> >>On Wed, 2006-01-04 at 16:42 -0800, Ulrich Drepper wrote: >> >>>Josh Boyer wrote: >>> >>>>Out of curiosity... why does it require 2.6.9 and higher? >>> >>>To get rid of all the compatibility crap for kernels < 2.6.9. >> > > It'll hit somebody who feels the need to keep that old 2.0.30 kernel > running or something.... And it'll start a big flamewar about how RedHat > keeps hosing people over because they are slaves to the almighty dollar > and don't care about the FOSS community. It'll then melt into a Gnome > vs KDE debate and various folks will chime in with "thats why I run > Gentoo now!"... > > Out of curiosity though, how much compatibility cruft has built up over > all this time? Is it a size issue? Maintenance? Performance even? > > -- Sincerely yours, Yura From fedora at leemhuis.info Fri Jan 6 10:41:02 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 06 Jan 2006 11:41:02 +0100 Subject: Heads-up: "RFC: kernel-modules in Fedora Extras" now on fedora-extras-list In-Reply-To: <1136543456.3146.19.camel@localhost.localdomain> References: <1136543456.3146.19.camel@localhost.localdomain> Message-ID: <1136544062.3146.30.camel@localhost.localdomain> Hi all! Sorry for crossposting, but I think a short heads-up is needed here. The Fedora Extras Steering Committee (FESCo) agreed on a standard for packaging kernel-modules in Fedora Extras. To look at the details see this mail: https://www.redhat.com/archives/fedora-extras-list/2006-January/msg00219.html The last chance to comment on it before it is getting used in devel/FC5 is: Now. Please use fedora-extras-list for the discussion -- please don't reply to this mail on this list. Instead click on reply and change the To: field to fedora-extras-list at redhat.com (the threading hopefully should work fine if you do it like this). Thanks! CU thl -- Thorsten Leemhuis From alan at redhat.com Fri Jan 6 11:51:47 2006 From: alan at redhat.com (Alan Cox) Date: Fri, 6 Jan 2006 06:51:47 -0500 Subject: CD Eject In-Reply-To: <1136488717.22333.42.camel@remedyz.boston.redhat.com> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> <1136488717.22333.42.camel@remedyz.boston.redhat.com> Message-ID: <20060106115147.GC11507@devserv.devel.redhat.com> On Thu, Jan 05, 2006 at 02:18:37PM -0500, John (J5) Palmieri wrote: > As for drives opening I would guess we could listen for the button press > and do an unmount/eject. The question is do we get eject button signals > from the kernel. Or from the hardware. Late ATA supports polling and the like for button changes but AFAIK nobody ever implemented the user space polling tool and most drives don't support it From fedora at iagorubio.com Fri Jan 6 12:00:59 2006 From: fedora at iagorubio.com (Iago Rubio) Date: Fri, 06 Jan 2006 13:00:59 +0100 Subject: edit root alias when installing the OS In-Reply-To: <3adc77210601051130h381ba9aao6cb36f3ca3abd964@mail.gmail.com> References: <1136149140.3230.5.camel@rivendell.home.local> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <43BD6216.4090206@redhat.com> <3adc77210601051130h381ba9aao6cb36f3ca3abd964@mail.gmail.com> Message-ID: <1136548860.4493.5.camel@speedy.iagorubio.net> On Thu, 2006-01-05 at 19:30 +0000, Naheem Zaffar wrote: > I believe adding the primary user to sudo should be an option on > firstboot. > > As a newbie it is almost scary adding your name to the sudoers file, > and is abit of guesswork. And you have to know it exists. Its less > scary to just use root. Not at all. You don't need to know where this file is placed. You must no to be scared at all to edit this file. Just use visudo(8). I will scream and stop on errors, and will open sudoers for you. -- Iago Rubio From ph18 at cornell.edu Fri Jan 6 16:27:56 2006 From: ph18 at cornell.edu (Paul A Houle) Date: Fri, 06 Jan 2006 11:27:56 -0500 Subject: edit root alias when installing the OS In-Reply-To: <1136490840.28143.3.camel@localhost> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> <1136490840.28143.3.camel@localhost> Message-ID: <43BE9A8C.6000703@cornell.edu> Richard Hughes wrote: > Agreed, a graphical tool would make it very easy to configure. Any > python hackers bored? > A graphical tool will make it very easy to screw up the sudoers file. From david at fubar.dk Fri Jan 6 18:49:53 2006 From: david at fubar.dk (David Zeuthen) Date: Fri, 06 Jan 2006 13:49:53 -0500 Subject: CD Eject In-Reply-To: <20060106115147.GC11507@devserv.devel.redhat.com> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> <1136488717.22333.42.camel@remedyz.boston.redhat.com> <20060106115147.GC11507@devserv.devel.redhat.com> Message-ID: <1136573393.2627.143.camel@daxter.boston.redhat.com> On Fri, 2006-01-06 at 06:51 -0500, Alan Cox wrote: > On Thu, Jan 05, 2006 at 02:18:37PM -0500, John (J5) Palmieri wrote: > > As for drives opening I would guess we could listen for the button press > > and do an unmount/eject. The question is do we get eject button signals > > from the kernel. > > Or from the hardware. Late ATA supports polling and the like for button > changes but AFAIK nobody ever implemented the user space polling tool and > most drives don't support it Since a recent release, we poll for this in HAL and emit a signal on the system message bus when the button is pressed. I believe recent version of gnome-volume-manager is able to intercept the signal and attempt the unmount / eject dance. Of course, the unmount operation might fail if one or some processes have open files on the media; I don't think g-v-m yet spams the user with a dialog a'la "The application Foo is preventing ejection of your optical disc" but I wouldn't be surprised if it does. Yes, it only works on some drives. David From rodd at clarkson.id.au Fri Jan 6 20:04:21 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sat, 07 Jan 2006 07:04:21 +1100 Subject: rawhide report: 20060104 changes In-Reply-To: <604aa7910601041506v1929d9c3yd432ab64c376a08a@mail.gmail.com> References: <200601040816.k048GeEX025112@porkchop.devel.redhat.com> <1136413580.3125.11.camel@localhost.localdomain> <604aa7910601041506v1929d9c3yd432ab64c376a08a@mail.gmail.com> Message-ID: <1136577862.2543.1.camel@localhost.localdomain> On Wed, 2006-01-04 at 18:06 -0500, Jeff Spaleta wrote: > On 1/4/06, Rodd Clarkson wrote: > > I get the following error: > > > > /usr/bin/gnome-session: error while loading shared libraries: > > libgnomecanvas-2.so.0 cannot open shared object file: No such file or > > directory. > > thats very interesting... > rpm -q --whatprovides libgnomecanvas-2.so.0 > that should return libgnomecanvas-2.13.0-1 > > does rpm -ql libgnomecanvas show a libgnomecanvas-2.so.0 on your system? > what does the /usr/lib/libgnomecanvas-2.so.0 symlink point to? > > did ldconfig fail to run correctly after updates? Turns out yum update didn't work quite right (but this might have been my fault - or not). All it better. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From drepper at redhat.com Fri Jan 6 20:13:54 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Fri, 06 Jan 2006 12:13:54 -0800 Subject: glibc-2.3.90-26 and older kernels In-Reply-To: <43BE4955.4070704@gmail.com> References: <43BC69AC.1010601@redhat.com> <1136421529.6316.0.camel@yoda.jdub.homelinux.org> <43BC6B63.3070101@redhat.com> <1136427119.18235.30.camel@dragon.sys.intra> <1136478790.2509.4.camel@dhollis-lnx.sunera.com> <43BE4955.4070704@gmail.com> Message-ID: <43BECF82.5030704@redhat.com> David Hollis wrote: > It'll hit somebody who feels the need to keep that old 2.0.30 kernel > running or something.... Well, that person has long been out of luck since we already required a minimum 2.4.20 kernel. Beside, glibc is really conservative as far as the kernel requirement goes. Other components closely tied to the kernel (like kudzu) require much more recent kernels. So, you cannot really run such old kernels unless you jump through hoops. How you can possibly arrive at the conclusion that Red Hat is "slave to the almighty dollar" I cannot fathom. This is an optimization which reduces the penalties people using the Fedora as it is have to pay. In addition it reduces the burden to support bugs in code on old systems, thereby improving the quality for the modern code. > Out of curiosity though, how much compatibility cruft has built up over > all this time? Is it a size issue? Maintenance? Performance even? Sufficiently. About 1k of code, all from hot paths. Some variables, tested in that code, are also gone. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From zaitcev at redhat.com Fri Jan 6 20:43:39 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 6 Jan 2006 12:43:39 -0800 Subject: CD Eject In-Reply-To: References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> Message-ID: <20060106124339.22c2d167.zaitcev@redhat.com> On Thu, 05 Jan 2006 15:57:53 +0100, Thomas M Steenholdt wrote: > Actually, IIRC, windows (or the drive itself) locks the drive door too > under operation, but the lock is released, as soon as it's not in use... That's right, and we do the same. Unfortunately for this case, a mount operation performs an open of the block device, so it's considered "in use" and that locks the door. The device driver does not know if an application had any files open within the filesystem... It may be possible to implement something like an unlock after a period of inactivity. But all implications have to be well thought out. For now just use "eject". It unmounts, too, so it's safer anyway. -- Pete From zaitcev at redhat.com Fri Jan 6 20:54:13 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 6 Jan 2006 12:54:13 -0800 Subject: USB storage question (was Re: CD Eject) In-Reply-To: <43BE440F.60900@mesias.co.uk> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> <1136488717.22333.42.camel@remedyz.boston.redhat.com> <43BE440F.60900@mesias.co.uk> Message-ID: <20060106125413.44cd02ce.zaitcev@redhat.com> > From: Cam > References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2 at mail.gmail.com> > <1136488717.22333.42.camel at remedyz.boston.redhat.com> > > First, never yank a mounted USB device. > [...] Cam didn't quote relevant headers, so I cannot be sure with whom I am disagreeing here, and I do not see the original message in the thread. Remedyz.boston is J5's box. Anyway, it's completely safe to yank a mounted USB device, as far as system is concerned. If someone disagrees, we'll meet at dawn. :-) Your data on it may suffer, but hey, that's called "freedom" (to hurt yourself). Current VFS orphans necessary files and inodes just fine in case of a forced umount. Even if there was no umount, ub correctly orphans the block device (actually, I think usb-storage and sd_mod try too). So you are "guaranteed" that the system won't oops. What is left is the filesystem integrity and delayed writes. Mounting with "sync" is harmful and slow, but I think we do not delay writes these days. So, it should be safe to look at LEDs and pull the device when they stop flashing. Seriously, people, USB devices are designed to be hotpluggable. -- Pete From seandarcy2 at gmail.com Fri Jan 6 21:15:43 2006 From: seandarcy2 at gmail.com (sean) Date: Fri, 06 Jan 2006 16:15:43 -0500 Subject: splotchy color on desktop background Message-ID: I've updated to rawhide, with the new funky fedora startup icon. The desktop background is a blue-gray. When I move a window across the desktop it leaves the desktop a slightly paler tone of blue-gray ( that is, where the window used to be.) Eventually the desktop is slightly splotchy from all various windows movements. No real problem, but it looks a little odd. sean From sundaram at redhat.com Fri Jan 6 22:57:17 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 07 Jan 2006 04:27:17 +0530 Subject: edit root alias when installing the OS In-Reply-To: <43BE9A8C.6000703@cornell.edu> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> <1136490840.28143.3.camel@localhost> <43BE9A8C.6000703@cornell.edu> Message-ID: <43BEF5CD.9020609@redhat.com> Paul A Houle wrote: > Richard Hughes wrote: > >> Agreed, a graphical tool would make it very easy to configure. Any >> python hackers bored? >> > > A graphical tool will make it very easy to screw up the sudoers file. On the contrary, graphical tools can make it easy as well as safe by designing and limiting the input as well as providing interactive warnings etc. Rahul From rodd at clarkson.id.au Fri Jan 6 23:49:54 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sat, 07 Jan 2006 10:49:54 +1100 Subject: rawhide report: 20060104 changes In-Reply-To: <1136577862.2543.1.camel@localhost.localdomain> References: <200601040816.k048GeEX025112@porkchop.devel.redhat.com> <1136413580.3125.11.camel@localhost.localdomain> <604aa7910601041506v1929d9c3yd432ab64c376a08a@mail.gmail.com> <1136577862.2543.1.camel@localhost.localdomain> Message-ID: <1136591394.7098.3.camel@localhost.localdomain> On Sat, 2006-01-07 at 07:04 +1100, Rodd Clarkson wrote: > On Wed, 2006-01-04 at 18:06 -0500, Jeff Spaleta wrote: > > On 1/4/06, Rodd Clarkson wrote: > > > I get the following error: > > > > > > /usr/bin/gnome-session: error while loading shared libraries: > > > libgnomecanvas-2.so.0 cannot open shared object file: No such file or > > > directory. > > > > thats very interesting... > > rpm -q --whatprovides libgnomecanvas-2.so.0 > > that should return libgnomecanvas-2.13.0-1 > > > > does rpm -ql libgnomecanvas show a libgnomecanvas-2.so.0 on your system? > > what does the /usr/lib/libgnomecanvas-2.so.0 symlink point to? > > > > did ldconfig fail to run correctly after updates? > > Turns out yum update didn't work quite right (but this might have been > my fault - or not). > > All it better. Hmmm, Just reading the thread on difficulties with the bash-3.1 update (earlier on this list) and I realized that I would have included the bash update as part of this update (as I hadn't yum updated in a couple of days). I wonder whether this caused the initial yum update to fail, but then re-running yum update (which is what I did to solve the problem) fixed it. It turns out that some of the updates from the initial run had installed, but most hadn't. Rerunning installed them all as expected. Not 100% sure, but I thought I had seen the terminal showing that the update had worked before rebooting (new kernel in update). Rodd -- "It's a fine line between denial and faith. It's much better on my side" From dwmw2 at infradead.org Sat Jan 7 01:05:08 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 07 Jan 2006 01:05:08 +0000 Subject: glibc-2.3.90-26 and older kernels In-Reply-To: <1136478790.2509.4.camel@dhollis-lnx.sunera.com> References: <43BC69AC.1010601@redhat.com> <1136421529.6316.0.camel@yoda.jdub.homelinux.org> <43BC6B63.3070101@redhat.com> <1136427119.18235.30.camel@dragon.sys.intra> <1136478790.2509.4.camel@dhollis-lnx.sunera.com> Message-ID: <1136595908.3929.33.camel@localhost.localdomain> On Thu, 2006-01-05 at 11:33 -0500, David Hollis wrote: > It'll then melt into a Gnome vs KDE debate and various folks will > chime in with "thats why I run Gentoo now!"... Oh, does Gentoo have KDE by default? I might try that then... -- dwmw2 From dhollis at davehollis.com Sat Jan 7 03:45:23 2006 From: dhollis at davehollis.com (David Hollis) Date: Fri, 06 Jan 2006 22:45:23 -0500 Subject: glibc-2.3.90-26 and older kernels In-Reply-To: <43BECF82.5030704@redhat.com> References: <43BC69AC.1010601@redhat.com> <1136421529.6316.0.camel@yoda.jdub.homelinux.org> <43BC6B63.3070101@redhat.com> <1136427119.18235.30.camel@dragon.sys.intra> <1136478790.2509.4.camel@dhollis-lnx.sunera.com> <43BE4955.4070704@gmail.com> <43BECF82.5030704@redhat.com> Message-ID: <1136605523.2265.6.camel@dhollis-lnx.sunera.com> On Fri, 2006-01-06 at 12:13 -0800, Ulrich Drepper wrote: > How you can possibly arrive at the conclusion that Red Hat is "slave to > the almighty dollar" I cannot fathom. This is an optimization which > reduces the penalties people using the Fedora as it is have to pay. In > addition it reduces the burden to support bugs in code on old systems, > thereby improving the quality for the modern code. > In case you missed it, I was being quite sarcastic. I have no problem at all with removing that kind of old cruft. glibc aside, I don't think you can easily run a 2.4 based kernel on a FC4/5 system anyway. I can just imagine all of the flame wars that people will want to start due to this rather innocuous change. Seems to happen all the time. -------------- 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 mike at flyn.org Sat Jan 7 03:50:29 2006 From: mike at flyn.org (W. Michael Petullo) Date: Fri, 6 Jan 2006 21:50:29 -0600 Subject: Disconnected LDAP Laptop Message-ID: <20060107035028.GA10725@imp.flyn.org> I am interested in allowing laptop users to integrate into an LDAP/Kerberos network but retain the ability to operate away from their network. When connected, LDAP will provide NSS data and authentication will be performed using kerberos. When disconnected, information will somehow be cached locally on the laptop. This seems to be an important feature and is generally expected in many environments. Some time ago I ran across the pam_ccreds PAM module[1]. This module caches authentication tokens locally and works well. Fedora provides a pam_ccreds package. On the other hand, caching NSS data does not yet seem to be solved. This means that, for example, UID's will not be resolved to usernames when an LDAP server is unavailable. There are currently two options that people claim are not optimal: 1. nss_updatedb[2] maintains a local cache of user and group information. Several individuals have claimed that this solution is not feasible for very large installations. 2. nscd, a solution within glibc, caches NSS data as it is requested. There is not massive transfer of NSS data involved. However, in order for nscd to support disconnected operation, its TTL must be set to a long period. This has the disadvantage that network information will not be updated on the client even if it changes. Given the two available options: Is nss_updatedb really unusable in large installations? Could nss_updatedb be modified to perform better? Could nscd be modified to serve this purpose more effectively? Does anyone else have any other solutions? Is a new solution required? See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145044 for more discussion. [1] http://www.padl.com/OSS/pam_ccreds.html [2] http://www.padl.com/OSS/nss_updatedb.html -- Mike :wq From sundaram at redhat.com Sat Jan 7 03:53:49 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 07 Jan 2006 09:23:49 +0530 Subject: glibc-2.3.90-26 and older kernels In-Reply-To: <1136605523.2265.6.camel@dhollis-lnx.sunera.com> References: <43BC69AC.1010601@redhat.com> <1136421529.6316.0.camel@yoda.jdub.homelinux.org> <43BC6B63.3070101@redhat.com> <1136427119.18235.30.camel@dragon.sys.intra> <1136478790.2509.4.camel@dhollis-lnx.sunera.com> <43BE4955.4070704@gmail.com> <43BECF82.5030704@redhat.com> <1136605523.2265.6.camel@dhollis-lnx.sunera.com> Message-ID: <43BF3B4D.3030606@redhat.com> David Hollis wrote: >On Fri, 2006-01-06 at 12:13 -0800, Ulrich Drepper wrote: > > > >>How you can possibly arrive at the conclusion that Red Hat is "slave to >>the almighty dollar" I cannot fathom. This is an optimization which >>reduces the penalties people using the Fedora as it is have to pay. In >>addition it reduces the burden to support bugs in code on old systems, >>thereby improving the quality for the modern code. >> >> >> > >In case you missed it, I was being quite sarcastic. I have no problem >at all with removing that kind of old cruft. glibc aside, I don't think >you can easily run a 2.4 based kernel on a FC4/5 system anyway. I can >just imagine all of the flame wars that people will want to start due to >this rather innocuous change. Seems to happen all the time. > > Sarcasm can easily be mistaken here with no tones and all those different cultures. Unless you work on a relatively tight knit group or just taking a jab at a buddy of yours I would avoid that or add emoticons. --- Rahul From buildsys at redhat.com Sat Jan 7 08:09:00 2006 From: buildsys at redhat.com (Build System) Date: Sat, 7 Jan 2006 03:09:00 -0500 Subject: rawhide report: 20060107 changes Message-ID: <200601070809.k07890j4009143@porkchop.devel.redhat.com> Updated Packages: anaconda-10.90.25-1 ------------------- * Fri Jan 06 2006 Jeremy Katz - 10.90.25-1 - no sr at Latn yet since the po files haven't been added * Fri Jan 06 2006 Jeremy Katz - 10.90.24-1 - move a11y stuff earlier - fix the text mode progress bar (pnasrat, #176367) - fix ppc drive unreadable warnings (#176024) - add serbian locales (#175611) - preserve review checkbox between combo box selections (dcantrell, #176212) - quote ethtool args (#176918) - various spacing cleanups (dcantrell) - a few fixes to the group selector (dcantrell) - don't try to make the timezone widget bigger than screen (clumens, #176025) - fix rescue mode traceback (clumens) - fix message wording on package retry (clumens, #155884) - quiet debug spew in anaconda.log (clumens, #171663) - add ppc rescue script from jkeating (#177003) aspell-sv-50:0.51-1 ------------------- * Fri Jan 06 2006 Ivana Varekova 50:0.51-1 - update to 0.51-0 authconfig-5.1.1-1 ------------------ * Fri Jan 06 2006 Tomas Mraz - 5.1.1-1 - print warning if PAM module is missing when the PAM configuration is saved (#168880) * Fri Dec 23 2005 Tomas Mraz - make child dialog preset code more robust (#176462) bash-3.1-2 ---------- * Fri Jan 06 2006 Tim Waugh 3.1-2 - No longer need loadables, mbinc or shellfunc patches. - Use literal single-quote in bash man page where appropriate (bug #177051). booty-0.63-1 ------------ * Fri Jan 06 2006 Peter Jones - 0.63-1 - don't write a log, for now. * Wed Jan 04 2006 Peter Jones - 0.62-1 - fix degraded raid detection for dmraid * Fri Dec 09 2005 Jesse Keating - 0.61-1.1 - rebuilt docbook-utils-0.6.14-5 ---------------------- * Thu Jan 05 2006 Tim Waugh 0.6.14-5 - Move dvi and ps tools into pdf sub-package (bug #174897). glib2-2.9.2-2 ------------- * Fri Jan 06 2006 Matthias Clasen - 2.9.2-2 - Update to 2.9.2 * Sun Dec 11 2005 Matthias Clasen - Specfile cosmetics glibc-2.3.90-29 --------------- * Fri Jan 06 2006 Jakub Jelinek 2.3.90-29 - update from CVS - make pthread_mutex_t an unnamed union again, as it affects libstdc++ ABI mangling * Fri Jan 06 2006 Jakub Jelinek 2.3.90-28 - update from CVS - make aio_suspend interruptible by signals (#171968) gnome-games-1:2.13.4-2 ---------------------- * Fri Jan 06 2006 Ray Strode 1:2.13.4-2 - remove "Windows" theme from gnobots gnome-power-manager-0.3.3-0.cvs.20060106 ---------------------------------------- * Fri Jan 06 2006 Jeremy Katz - 0.3.3-0.cvs.20060106 - update to a cvs snap so that it works with hal cvs snap - make sure we use libnotify groff-1.18.1.1-7 ---------------- * Fri Jan 06 2006 Jindrich Novy - 1.18.1.1-7 - require X dependencies only for gxditview (#177118) - work if bash's noclobber is on (#127492) gstreamer-0.10.1-1 ------------------ * Fri Jan 06 2006 John (J5) Palmieri - 0.10.1-1 - New upstream version * Fri Dec 16 2005 Thomas Vander Stichele - 0.10.0-1 - rebuilt for Fedora Core Development * Wed Dec 14 2005 Thomas Vander Stichele - 0.10.0-0.gst.2 - rebuilt against newer GLib and friends gstreamer-plugins-base-0.10.1-1 ------------------------------- * Fri Jan 06 2006 John (J5) Palmieri - 0.10.1-1 - New upstream version - gst-launch removed from upstream gstreamer08-plugins-0.8.11-3 ---------------------------- * Fri Jan 06 2006 John (J5) Palmieri - 0.8.11.3 - Obsolete the old gstreamer-plugins package java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_60rh ------------------------------------------ * Fri Jan 06 2006 Archit Shah - 0:1.4.2.0-40jpp_60rh - Import java-gcj-compat 1.0.48. kernel-2.6.15-1.1826.2.4_FC5 ---------------------------- * Fri Jan 06 2006 Dave Jones - Branch CVS for test2. - Add timer quirk for ATI chipsets. - Reboot through BIOS on HP laptops. - Additional check in x86 edid parser. - power up pwc webcam by default - don't confuse wireless security lock as a mouse. - Hush some debug messages in w1 driver. - Disable input layer on iseries. - VM OOM killer tweaks. - Flip IO scheduler to 'AS' by default again. (CFQ has slab corruption bugs right now). - Enable nvram driver for x86-64 - Fix posix-cpu-timers sched_time accumulation. * Thu Jan 05 2006 Dave Jones - Try to debug some negative pagecount errors. libofx-0.8.0-2 -------------- * Fri Jan 06 2006 Nalin Dahyabhai 0.8.0-2 - rebuild libselinux-1.29.4-1 ------------------- * Sat Jan 07 2006 Dan Walsh 1.29.4-1 - Upgrade to latest from NSA * Added format attribute to myprintf in matchpathcon.c and removed obsoleted rootlen variable in init_selinux_config(). * Wed Jan 04 2006 Dan Walsh 1.29.3-2 - Build with new libsepol * Wed Jan 04 2006 Dan Walsh 1.29.3-1 - Upgrade to latest from NSA * Merged several fixes and improvements from Ulrich Drepper (Red Hat), including: - corrected use of getline - further calls to __fsetlocking for local files - use of strdupa and asprintf - proper handling of dirent in booleans code - use of -z relro - several other optimizations * Merged getpidcon python wrapper from Dan Walsh (Red Hat). libsemanage-1.5.9-1 ------------------- * Sat Jan 07 2006 Dan Walsh 1.5.9-1 - Upgrade to latest from NSA * Merged const in APIs patch from Ivan Gyurdiev. * Merged validation of local file contexts patch from Ivan Gyurdiev. * Merged compare2 function patch from Ivan Gyurdiev. * Merged hidden def/proto update patch from Ivan Gyurdiev. libsepol-1.11.7-1 ----------------- * Sat Jan 07 2006 Dan Walsh 1.11.7-1 - Upgrade to latest from NSA * Merged const in APIs patch from Ivan Gyurdiev. * Merged compare2 function patch from Ivan Gyurdiev. * Fixed hierarchy checker to only check allow rules. man-pages-2.20-1 ---------------- * Fri Jan 06 2006 Ivana Varekova 2.20-1 - update to 2.20 * Tue Dec 13 2005 Ivana Varekova 2.16-2 - fix bug 174628 - mmap(2) CAN return mappings at location 0 mod_auth_pgsql-2.0.3-2 ---------------------- * Fri Jan 06 2006 Joe Orton 2.0.3-2 - update to 2.0.3 (includes fix for CVE-2005-3656) openjade-1.3.2-23 ----------------- * Fri Jan 06 2006 Tim Waugh 1.3.2-23 - Rebuild against new opensp. pup-0.9.2-1 ----------- * Fri Jan 06 2006 Jeremy Katz - 0.9.2-1 - add a scrollbar to the details text buffer selinux-policy-2.1.7-3 ---------------------- * Thu Jan 05 2006 Dan Walsh 2.1.7-3 - Handle new location of hal scripts * Thu Jan 05 2006 Dan Walsh 2.1.7-2 - Allow su to read /etc/mtab shadow-utils-2:4.0.14-1 ----------------------- * Fri Jan 06 2006 Peter Vrabec 2:4.0.14-1 - upgrade totem-1.3.0-3 ------------- * Fri Jan 06 2006 John (J5) Palmieri 1.3.0-3 - Build with gstreamer 0.10 - Enable the mozilla plugin tzdata-2005r-2 -------------- * Thu Jan 05 2006 Petr Machata 2005r-2 - 2005r - Zones EST, MST, HST, EST5EDT, CST6CDT, MST7MDT, PST8PDT moved to northamerica to guard against old files with obsolete information being left in the time zone binary directory. - Changes for countries that are supposed to join 2007 US DST change. This includes most of Canada, however entries already in the database (Alberta, British Columbia, Newfoundland, Northwest Territories, and Yukon) were left alone for the time being. - Fixes in zdump.c (abbrok): conditions are chained, and the string is checked for emptiness. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5smp jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 openhpi - 2.2.1-1.i386 requires libnetsnmp.so.9 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 openhpi - 2.2.1-1.ppc requires libnetsnmp.so.9 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) openhpi - 2.2.1-1.ppc64 requires libnetsnmp.so.9()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 openhpi - 2.2.1-1.s390 requires libnetsnmp.so.9 Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) openhpi - 2.2.1-1.s390x requires libnetsnmp.so.9()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) openhpi - 2.2.1-1.x86_64 requires libnetsnmp.so.9()(64bit) From pemboa at gmail.com Sat Jan 7 08:40:49 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 7 Jan 2006 02:40:49 -0600 Subject: edit root alias when installing the OS In-Reply-To: <43BE9A8C.6000703@cornell.edu> References: <1136149140.3230.5.camel@rivendell.home.local> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> <1136490840.28143.3.camel@localhost> <43BE9A8C.6000703@cornell.edu> Message-ID: <16de708d0601070040q75f72556p381a392f693f207f@mail.gmail.com> On 1/6/06, Paul A Houle wrote: > > Richard Hughes wrote: > > Agreed, a graphical tool would make it very easy to configure. Any > > python hackers bored? > > > A graphical tool will make it very easy to screw up the sudoers file. > > How would it do that? -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathanhueber at hotmail.com Sat Jan 7 17:48:11 2006 From: jonathanhueber at hotmail.com (Jonathan Hueber) Date: Sat, 07 Jan 2006 18:48:11 +0100 Subject: (no subject) Message-ID: Hi, I may be posting in an inappropriate place, seeing as this is really the Fedora Core development list... I noticed that libselinux as obtained from the NSA's website has gained a Python interface. While I have no objections to extra features, would it be possible to have a Makefile target just for the straight C based library? I am building an SE Linux deployment from scratch and SELinux is a dependency for LibC, etc. I don't really want Python on the box at all (not even at build time). If needs be I can contribute a patch to do this (although it'd be better if it were done by someone who knows *exactly* what they are doing!). Thanks, JH _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From jonathanhueber at hotmail.com Sat Jan 7 18:08:53 2006 From: jonathanhueber at hotmail.com (Jonathan Hueber) Date: Sat, 07 Jan 2006 19:08:53 +0100 Subject: [PATCH] LibSELinux Python dependency whinge Message-ID: Hi, Seeing as I am taking up your time, I may as well provide my patch. Licensed as the rest of libselinux (public domain). The following provides two new make targets for libselinux.so: "make all-nopython" and "make install-nopython" The top level Makefile needs the following additions: all-nopython: $(MAKE) -C src all-nopython $(MAKE) -C utils install-nopython: $(MAKE) -C include install $(MAKE) -C src install-nopython $(MAKE) -C utils install $(MAKE) -C man install The Makefile in the src directory needs the following changes (note that this splits up the old "install" target). install-libselinux: test -d $(LIBDIR) || install -m 755 -d $(LIBDIR) install -m 644 $(LIBA) $(LIBDIR) test -d $(SHLIBDIR) || install -m 755 -d $(SHLIBDIR) install -m 755 $(LIBSO) $(SHLIBDIR) cd $(LIBDIR) && ln -sf ../../`basename $(SHLIBDIR)`/$(LIBSO) $(TARGET) all-nopython: $(LIBA) $(LIBSO) install-nopython: install-libselinux install: all install-pywrap install-libselinux Seems to work for me. Keep up the good work! JH _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From seg at haxxed.com Sat Jan 7 22:52:36 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 07 Jan 2006 16:52:36 -0600 Subject: edit root alias when installing the OS In-Reply-To: <1136517305.2899.19.camel@locolhost.localdomain> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> Message-ID: <1136674356.23159.2.camel@hamburger.booze> On Thu, 2006-01-05 at 19:15 -0800, Michael A. Peters wrote: > I can't speak for Ubuntu - but OS X has a root account. > > sudo su - > > and you are root. Well any unix is not likely to get rid of root entirely, but you can eliminate the password on the account and discourage its direct use. > It weakens OS X because by default, every admin password is essentially > a root password. I'm not seeing a convincing argument as to why this is any worse than every admin knowing the root password. > In the early days it was *really* bad - as one could from a local > account do nidump passwd . and then run it through jtr to crack weak > admin passwords (and thus root the box). At least now they finally have > some sort of shadow implemented to prevent that. I don't see how weak passwords are sudo's fault. -------------- 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 n0dalus+redhat at gmail.com Sun Jan 8 02:51:42 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sun, 8 Jan 2006 13:21:42 +1030 Subject: edit root alias when installing the OS In-Reply-To: <1136674356.23159.2.camel@hamburger.booze> References: <1136149140.3230.5.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> <1136674356.23159.2.camel@hamburger.booze> Message-ID: <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> On 1/8/06, Callum Lerwick wrote: > On Thu, 2006-01-05 at 19:15 -0800, Michael A. Peters wrote: > > I can't speak for Ubuntu - but OS X has a root account. > > > > sudo su - > > > > and you are root. > > Well any unix is not likely to get rid of root entirely, but you can > eliminate the password on the account and discourage its direct use. Why should we cripple people's ability to administrate their systems by taking away the root password? If I had to prepend all my commands with 'sudo' and half of my paths with '/sbin' I'd quickly get frustrated and give root a password. You can discourage the direct use of root by not letting root login at gdm until they press a key-combo, or warning if they open a web browser or something -- but removing the concept of root is not discouraging it, it's just dumbing UNIX down. I think people can handle the concept of a single superuser -- it's one of the biggest security advantages of UNIX over some other popular operating systems where almost every user is an admin. > > > It weakens OS X because by default, every admin password is essentially > > a root password. > > I'm not seeing a convincing argument as to why this is any worse than > every admin knowing the root password. The issue is that: Just because admins know the root password doesn't mean any malware that manages to sneak on does too. Putting all the users in sudoers means that malware only needs to get a user password for root access, which is usually much easier than obtaining the root password. If there are admins that you can't trust 100% with the root password, you shouldn't be giving them sudo access either (unless you really tighten down sudoers and deny-by-default, which probably won't come as a default configuration). > > > In the early days it was *really* bad - as one could from a local > > account do nidump passwd . and then run it through jtr to crack weak > > admin passwords (and thus root the box). At least now they finally have > > some sort of shadow implemented to prevent that. > > I don't see how weak passwords are sudo's fault. > Weak passwords are not sudo's fault, but statistically the more users in sudoers the easier it becomes to get root access. It doesn't matter how strong the passwords are. I think the current system is fine as it is -- I don't see why some people are so keen on removing the root password. If you are on a multi-admin system, then a well configured sudo is great, but root should still have a password. Putting users by default into an allow-everything sudoers is weakening one of UNIX's most effective layers of security. n0dalus. From mpeters at mac.com Sun Jan 8 06:09:57 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 07 Jan 2006 22:09:57 -0800 Subject: edit root alias when installing the OS In-Reply-To: <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> <1136674356.23159.2.camel@hamburger.booze> <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> Message-ID: <1136700598.3848.5.camel@locolhost.localdomain> On Sun, 2006-01-08 at 13:21 +1030, n0dalus wrote: > > I think the current system is fine as it is -- I don't see why some > people are so keen on removing the root password. If I were modifying Fedora for desktop users (and I don't think this is a safe general default - but if say I was Dell or someone selling Linux for the Desktop based on Fedora) - I would make the following change - I would make an option to add the firstboot user to the wheel group. The gui sysconfig-* tools (with perhaps a few exceptions) - if the tool is requested by the pam_console user AND the user is a member of the wheel group, that would be sufficient authentication to run the tool without root password. I would not do it for the user administration tool, however - I would still require root password to manage system users. But sound card detection, network device configuration, Printing, etc. - that's how I would do it. It doesn't require use of sudo, or use of the command line at all. From n0dalus+redhat at gmail.com Sun Jan 8 07:32:03 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sun, 8 Jan 2006 18:02:03 +1030 Subject: edit root alias when installing the OS In-Reply-To: <1136700598.3848.5.camel@locolhost.localdomain> References: <1136149140.3230.5.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> <1136674356.23159.2.camel@hamburger.booze> <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> <1136700598.3848.5.camel@locolhost.localdomain> Message-ID: <6280325c0601072332v3a491ac3kc27af01794bbbdc3@mail.gmail.com> On 1/8/06, Michael A. Peters wrote: > On Sun, 2006-01-08 at 13:21 +1030, n0dalus wrote: > > > > > I think the current system is fine as it is -- I don't see why some > > people are so keen on removing the root password. > > If I were modifying Fedora for desktop users (and I don't think this is > a safe general default - but if say I was Dell or someone selling Linux > for the Desktop based on Fedora) - I would make the following change - > > I would make an option to add the firstboot user to the wheel group. > The gui sysconfig-* tools (with perhaps a few exceptions) - if the tool > is requested by the pam_console user AND the user is a member of the > wheel group, that would be sufficient authentication to run the tool > without root password. > > I would not do it for the user administration tool, however - I would > still require root password to manage system users. But sound card > detection, network device configuration, Printing, etc. - that's how I > would do it. It doesn't require use of sudo, or use of the command line > at all. > Perhaps a better option, while it might require a lot of development, is to let users do more things without touching the actual system (or it could be handled by a daemon). Things like Printing, network device configuration, sound cards, system language settings etc might all be changeable on a per-user basis (with some restrictions) without you having to run anything with higher-privileges. For example, using system-config-language would change the Language for the current user only -- other users are not affected by the change. My non-English speaking friends could easily have an account on my computer and set their own language with a graphical tool, without me changing the language for the entire system (this is probably possible already, but I don't know how.) There could be a tickbox to set the default language for all users, and it would ask you for the root password before proceeding. Moving more settings and even some drivers into non-root userspace allows for better management without needing to have users enter the root password. I know this would all involve a lot of work and might introduce problems, but I think parts of Linux are heading this way already. n0dalus. From mpeters at mac.com Sun Jan 8 07:48:54 2006 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 07 Jan 2006 23:48:54 -0800 Subject: edit root alias when installing the OS In-Reply-To: <6280325c0601072332v3a491ac3kc27af01794bbbdc3@mail.gmail.com> References: <1136149140.3230.5.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> <1136674356.23159.2.camel@hamburger.booze> <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> <1136700598.3848.5.camel@locolhost.localdomain> <6280325c0601072332v3a491ac3kc27af01794bbbdc3@mail.gmail.com> Message-ID: <1136706535.3848.10.camel@locolhost.localdomain> On Sun, 2006-01-08 at 18:02 +1030, n0dalus wrote: > > Perhaps a better option, while it might require a lot of development, > is to let users do more things without touching the actual system (or > it could be handled by a daemon). Things like Printing, network device > configuration, sound cards, system language settings etc might all be > changeable on a per-user basis (with some restrictions) without you > having to run anything with higher-privileges. For example, using > system-config-language would change the Language for the current user > only -- other users are not affected by the change. I believe that is the current way language is done. I know you can select it at the gdm window, and I don't recall needing to use the root password to change keyboard layout last time I had need to. Sound card is a little harder because it requires loading a kernel module, printing could be done probably through cups w/o needing root - though privilege to alter the cups profile to add a printer would be needed (at least in some cases, kudzu does a pretty good job at picking up directly attached printers) From buildsys at redhat.com Sun Jan 8 08:43:56 2006 From: buildsys at redhat.com (Build System) Date: Sun, 8 Jan 2006 03:43:56 -0500 Subject: rawhide report: 20060108 changes Message-ID: <200601080843.k088huaI032183@porkchop.devel.redhat.com> Updated Packages: booty-0.64-1 ------------ * Sat Jan 07 2006 Jeremy Katz - 0.64-1 - fix syntax error eclipse-1:3.1.1-1jpp_15fc ------------------------- * Wed Jan 04 2006 Andrew Overholt 3.1.1-1jpp_15fc - Update s390{,x} patches. - Use natively-compiled ecj during build. - Attempt build on ia64. - Change about_files to be i386 and x86_64 only (will patch file upstream). gcc-4.1.0-0.14 -------------- * Fri Jan 06 2006 Jakub Jelinek 4.1.0-0.14 - update from gcc-4_1-branch (-r109369:109401) - PR fortran/23675 - fix Java shutdown hook (Tom Tromey, #165136) - fix libjava/shlibpath.m4 (PR libgcj/24940) * Thu Jan 05 2006 Jakub Jelinek 4.1.0-0.13 - update from gcc-4_1-branch (-r108957:109369) - PRs c++/23171, c++/23172, c++/24671, c++/24782, c++/25294, c++/25417, c++/25439, c++/25492, c++/25625, c++/25632, c++/25633, c++/25634, c++/25635, c++/25637, c++/25638, c/25183, c/25559, debug/25562, fortran/18990, fortran/19362, fortran/20244, fortran/20862, fortran/20864, fortran/20889, fortran/22607, fortran/23152, fortran/25018, fortran/25053, fortran/25055, fortran/25063, fortran/25064, fortran/25066, fortran/25067, fortran/25068, fortran/25069, fortran/25106, fortran/25391, fortran/25532, fortran/25586, fortran/25587, libgcj/9715, libgcj/19132, libgfortran/25139, libgfortran/25419, libgfortran/25510, libgfortran/25550, libgfortran/25594, middle-end/24827, objc/25328, rtl-optimization/21041, rtl-optimization/25130, target/24342, target/25554, target/25572, testsuite/25214, testsuite/25441, testsuite/25442, testsuite/25444, tree-opt/25513 - create java Package for compiled classes which are linked in but loaded by the system class loader (Tom Tromey, #176956) - fix posix_memalign prototype in (#176461) - update from gomp-20050608-branch (up to -r109349) - buildrequire libXtst-devel (#176898) - fix built in path to classmap.db on x86_64, s390x and ppc64 (#176562) - fix debug info for preprocessed Fortran code (#175071, PR fortran/25324) kernel-2.6.15-1.1826.2.5_FC5 ---------------------------- * Sat Jan 07 2006 Dave Jones - Silence some iseries build warnings. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5smp jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 openhpi - 2.2.1-1.i386 requires libnetsnmp.so.9 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 openhpi - 2.2.1-1.ppc requires libnetsnmp.so.9 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) openhpi - 2.2.1-1.ppc64 requires libnetsnmp.so.9()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 openhpi - 2.2.1-1.s390 requires libnetsnmp.so.9 Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) openhpi - 2.2.1-1.s390x requires libnetsnmp.so.9()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) openhpi - 2.2.1-1.x86_64 requires libnetsnmp.so.9()(64bit) From ivazquez at ivazquez.net Sun Jan 8 12:11:51 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 08 Jan 2006 07:11:51 -0500 Subject: Python namespace in packages Message-ID: <1136722311.5036.2.camel@ignacio.lan> One thing I've always wondered is why a Python namespace isn't being used even though it's one of the primary languages used in Fedora. It doesn't make any sense to me why they aren't implemented. Does anyone have a reasonable explanation of why not? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 tomo.vuckovic at gmail.com Sun Jan 8 12:17:26 2006 From: tomo.vuckovic at gmail.com (Tomo Vuckovic) Date: Sun, 08 Jan 2006 13:17:26 +0100 Subject: cairo fail gcc4 build Message-ID: <43C102D6.4070909@gmail.com> Problem build cairo 1.0.2 on Fedora rawhide. fbpict.c: At top level: fbpict.c:79: warning: 'fbIn24' defined but not used {standard input}: Assembler messages: {standard input}:8656: Error: symbol `_cairo_pixman_composite' is already defined make[3]: *** [fbpict.lo] Error 1 make[3]: Leaving directory `/usr/src/atomix/BUILD/cairo-1.0.2/pixman/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/atomix/BUILD/cairo-1.0.2/pixman' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/atomix/BUILD/cairo-1.0.2' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.54023 (%build) Attached is a patch that fixes. Best regards, Tomo -------------- next part -------------- A non-text attachment was scrubbed... Name: cairo-1.0.2-gcc4.patch Type: text/x-patch Size: 751 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tomo.vuckovic.vcf Type: text/x-vcard Size: 209 bytes Desc: not available URL: From tomo.vuckovic at gmail.com Sun Jan 8 13:13:31 2006 From: tomo.vuckovic at gmail.com (Tomo Vuckovic) Date: Sun, 08 Jan 2006 14:13:31 +0100 Subject: cairo fail gcc4 build Message-ID: <43C10FFB.2060003@gmail.com> Problem build cairo 1.0.2 on Fedora rawhide. fbpict.c: At top level: fbpict.c:79: warning: 'fbIn24' defined but not used {standard input}: Assembler messages: {standard input}:8656: Error: symbol `_cairo_pixman_composite' is already defined make[3]: *** [fbpict.lo] Error 1 make[3]: Leaving directory `/usr/src/atomix/BUILD/cairo-1.0.2/pixman/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/atomix/BUILD/cairo-1.0.2/pixman' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/atomix/BUILD/cairo-1.0.2' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.54023 (%build) Attached is a patch that fixes. Best regards, Tomo ------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: cairo-1.0.2-gcc4.patch Type: text/x-patch Size: 751 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tomo.vuckovic.vcf Type: text/x-vcard Size: 209 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Sun Jan 8 13:22:13 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Sun, 08 Jan 2006 13:22:13 +0000 Subject: cairo fail gcc4 build In-Reply-To: <43C102D6.4070909@gmail.com> References: <43C102D6.4070909@gmail.com> Message-ID: <1136726533.3041.12.camel@T7.Linux> Hi, On Sun, 2006-01-08 at 13:17 +0100, Tomo Vuckovic wrote: > Attached is a patch that fixes. Shouldn't this be in bugzilla? Actually this and the long standing vte bug means that mono cannot be fully built? Secret agenda anyone ;-p TTFN Paul -- main(t,_,a) char*a;{return!0 I noticed that there are no Wireless entry in system-config-network-tui, and there is in system-config-network-gui. BTW what ever I do, I can't make my wep key working with that tool, and some more advanced options. Sometimes is much more easier to put my own scripts in /etc/rc.d/rc.local, such as: /sbin/iwconfig wlan0 key restricted XXXXXXXXXX /sbin/iwconfig wlan0 rate 54M /sbin/iwconfig wlan0 channel 11 It would be very nice if you make ncurces based version of all the system-config tools and to improve some of them, such as network tool. Cheers! -- Igor Jagec From sundaram at redhat.com Sun Jan 8 15:22:00 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 08 Jan 2006 20:52:00 +0530 Subject: system-config-network-tui In-Reply-To: <43C12B6A.8090602@vip.hr> References: <43C12B6A.8090602@vip.hr> Message-ID: <43C12E18.1060402@redhat.com> Igor Jagec wrote: >I noticed that there are no Wireless entry in system-config-network-tui, >and there is in system-config-network-gui. BTW what ever I do, I can't >make my wep key working with that tool, and some more advanced options. >Sometimes is much more easier to put my own scripts in >/etc/rc.d/rc.local, such as: > >/sbin/iwconfig wlan0 key restricted XXXXXXXXXX >/sbin/iwconfig wlan0 rate 54M >/sbin/iwconfig wlan0 channel 11 > > If you are working on wireless connections, Network Manager might be more appropriate http://fedoraproject.org/wiki/Tools/NetworkManager >It would be very nice if you make ncurces based version of all the >system-config tools and to improve some of them, such as network tool. > >Cheers! > > Some of them already have text user interfaces. If you want to work on other tools, you can use Fedora Extras as a gateway. It's enabled by default, you get CVS space, build system access, peer reviews and so on. -- Rahul Fedora Bug Triaging - http://fedorproject.org/wiki/BugZappers From igorm5 at vip.hr Sun Jan 8 15:40:54 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Sun, 08 Jan 2006 16:40:54 +0100 Subject: system-config-network-tui In-Reply-To: <43C12E18.1060402@redhat.com> References: <43C12B6A.8090602@vip.hr> <43C12E18.1060402@redhat.com> Message-ID: <43C13286.2080408@vip.hr> Rahul Sundaram wrote: > If you are working on wireless connections, Network Manager might be > more appropriate http://fedoraproject.org/wiki/Tools/NetworkManager I don't like that tool. It breaks my wireless connection very often. I removed it from my system immediately. I read some experiences on news groups about breaking ADSL connection, and so on. >>It would be very nice if you make ncurces based version of all the >>system-config tools and to improve some of them, such as network tool. > Some of them already have text user interfaces. If you want to work on > other tools, you can use Fedora Extras as a gateway. It's enabled by > default, you get CVS space, build system access, peer reviews and so on. As soon as I get some basic programming skills, thanks :) -- Igor Jagec From sundaram at redhat.com Sun Jan 8 15:43:08 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 08 Jan 2006 21:13:08 +0530 Subject: system-config-network-tui In-Reply-To: <43C13286.2080408@vip.hr> References: <43C12B6A.8090602@vip.hr> <43C12E18.1060402@redhat.com> <43C13286.2080408@vip.hr> Message-ID: <43C1330C.6050408@redhat.com> Igor Jagec wrote: >Rahul Sundaram wrote: > > > >>If you are working on wireless connections, Network Manager might be >>more appropriate http://fedoraproject.org/wiki/Tools/NetworkManager >> >> > >I don't like that tool. It breaks my wireless connection very often. I >removed it from my system immediately. I read some experiences on news >groups about breaking ADSL connection, and so on. > > If there are bugs, report them in bugzilla or post to the relevant mailing list for discussion http://mail.gnome.org/mailman/listinfo/networkmanager-list and you will probably find news groups discussing with bugs on everything there is out there :) -- Rahul Fedora Bug Triaging - http://fedorproject.org/wiki/BugZappers From fedora at adslpipe.co.uk Sun Jan 8 15:52:05 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sun, 08 Jan 2006 15:52:05 +0000 Subject: system-config-network-tui In-Reply-To: <43C1330C.6050408@redhat.com> References: <43C12B6A.8090602@vip.hr> <43C12E18.1060402@redhat.com><43C13286.2080408@vip.hr> <43C1330C.6050408@redhat.com> Message-ID: <43C13525.1070605@adslpipe.co.uk> Rahul Sundaram wrote: > Fedora Bug Triaging - http://fedorproject.org/wiki/BugZappers What is this FedorProject :-P From igorm5 at vip.hr Sun Jan 8 15:53:47 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Sun, 08 Jan 2006 16:53:47 +0100 Subject: system-config-network-tui In-Reply-To: <43C1330C.6050408@redhat.com> References: <43C12B6A.8090602@vip.hr> <43C12E18.1060402@redhat.com> <43C13286.2080408@vip.hr> <43C1330C.6050408@redhat.com> Message-ID: <43C1358B.6000202@vip.hr> Rahul Sundaram wrote: > Igor Jagec wrote: >>I don't like that tool. It breaks my wireless connection very often. I >>removed it from my system immediately. I read some experiences on news >>groups about breaking ADSL connection, and so on. > If there are bugs, report them in bugzilla or post to the relevant > mailing list for discussion > http://mail.gnome.org/mailman/listinfo/networkmanager-list and you will > probably find news groups discussing with bugs on everything there is > out there :) You're right. I'll install it on my Rawhide system and try to play with it. BTW I didn't know that is text tools, I played only with GNOME applet of Network Manager. -- Igor Jagec From sundaram at redhat.com Sun Jan 8 15:53:57 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 08 Jan 2006 21:23:57 +0530 Subject: system-config-network-tui In-Reply-To: <43C13525.1070605@adslpipe.co.uk> References: <43C12B6A.8090602@vip.hr> <43C12E18.1060402@redhat.com><43C13286.2080408@vip.hr> <43C1330C.6050408@redhat.com> <43C13525.1070605@adslpipe.co.uk> Message-ID: <43C13595.50300@redhat.com> Andy Burns wrote: > Rahul Sundaram wrote: > >> Fedora Bug Triaging - http://fedorproject.org/wiki/BugZappers > > > What is this FedorProject :-P > A bug of course. Thats what happens when you write signatures on 2 AM. fixed. Thanks -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From Tommy.Reynolds at MegaCoder.com Sun Jan 8 17:29:42 2006 From: Tommy.Reynolds at MegaCoder.com (Tommy Reynolds) Date: Sun, 8 Jan 2006 11:29:42 -0600 Subject: edit root alias when installing the OS In-Reply-To: <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> <1136674356.23159.2.camel@hamburger.booze> <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> Message-ID: <20060108112942.cbfe7def.Tommy.Reynolds@MegaCoder.com> Uttered n0dalus , spake thus: > Why should we cripple people's ability to administrate their systems > by taking away the root password? If I had to prepend all my commands > with 'sudo' and half of my paths with '/sbin' I'd quickly get > frustrated and give root a password. So put "/sbin" on your normal path. Well, doing a significant amount of work as root does seem to justify sudo'ing into the root account: $ sudo su - But the proper /etc/sudoers entry would let only _your_ account run _only_ that program and require _your_ password to do it. At least you'd get an audit trail entry as you entered the superuser realm. With a root login, you get *nothing*. Was that a hostile root login? You can only hope not. > Just because admins know the root password doesn't mean any malware > that manages to sneak on does too. Putting all the users in sudoers > means that malware only needs to get a user password for root access, > which is usually much easier than obtaining the root password. Not really. To break into a UNIX system, I need to have two items: a valid account name, and a valid password. With the "root" account, I'm halfway there already. > Weak passwords are not sudo's fault, but statistically the more users > in sudoers the easier it becomes to get root access. It doesn't matter > how strong the passwords are. The idea is not to C3 secure the whole environment (that's another show ;-) but to help Aunt Minerva (substitute your favorite non-technical user name here) get help when something gets bungled while in superuser mode. At least there is an audit trail so the help desk can get a glimmer of what was actually done rather than what the semi-inept user thought was being done. The goal, at least of my original posting, was to encourage newbies to use the sudo method for those times they need superuser privilege. Reading the sudo(1) man page gives pause even to seasoned admins and probably drives newbies back screaming to Google.com for another command. Yet, sudo(1) is probably the safest was to superuser command line access for casual admin activity. Thus the need to gently steer newbies to sudo(1) for, maybe, some set of common root commands. Sudo(1) is not intended to outlaw su(8) for real admins and power users. As we try to promote Linux on the desktop and in the home, depending on more casual admins, we need more audit trails, not fewer, so the savy among us can help when disaster ensues. Sudo(1) or su(8) issues aside, disaster _will_ ensue, so why not try for the most well-paved path? Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mailinglists at erwinrol.com Sun Jan 8 23:24:36 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 09 Jan 2006 00:24:36 +0100 Subject: Radeon driver hang In-Reply-To: <1135172630.3105.2.camel@xpc.home.erwinrol.com> References: <1135172630.3105.2.camel@xpc.home.erwinrol.com> Message-ID: <1136762676.19795.2.camel@xpc.home.erwinrol.com> On Wed, 2005-12-21 at 14:43 +0100, Erwin Rol wrote: > Hey all, > > I added Benjamin's patch to the ati driver SRPM to test if it works, and > for me it seems to work, my machine doesn't hard hang anymore. > I updated the radeon driver SRPM of rawhide with the patch from Benjamin, because the RC4 version caused hangs again on my radeon. For the brave that want to try it you can find it here; http://www.erwinrol.com/downloads/software/xorg-x11-drv-ati-6.5.7.2-1.ER.1.src.rpm (Look Mike correct release number ;-) - Erwin From seg at haxxed.com Mon Jan 9 02:27:11 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 08 Jan 2006 20:27:11 -0600 Subject: edit root alias when installing the OS In-Reply-To: <1136700598.3848.5.camel@locolhost.localdomain> References: <1136149140.3230.5.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> <1136674356.23159.2.camel@hamburger.booze> <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> <1136700598.3848.5.camel@locolhost.localdomain> Message-ID: <1136773632.18058.10.camel@localhost.localdomain> On Sat, 2006-01-07 at 22:09 -0800, Michael A. Peters wrote: > If I were modifying Fedora for desktop users I've been a devoted Fedora/Red Hat user since Red Hat 5.2 because I've found it to be the most mature and well thought out distribution for desktop use. (Well, at least since RH 7.0...) My servers run Debian. -------------- 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 seg at haxxed.com Mon Jan 9 02:27:11 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 08 Jan 2006 20:27:11 -0600 Subject: edit root alias when installing the OS In-Reply-To: <1136700598.3848.5.camel@locolhost.localdomain> References: <1136149140.3230.5.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> <1136674356.23159.2.camel@hamburger.booze> <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> <1136700598.3848.5.camel@locolhost.localdomain> Message-ID: <1136773632.18058.9.camel@localhost.localdomain> On Sat, 2006-01-07 at 22:09 -0800, Michael A. Peters wrote: > If I were modifying Fedora for desktop users I've been a devoted Fedora/Red Hat user since Red Hat 5.2 because I've found it to be the most mature and well thought out distribution for desktop use. (Well, at least since RH 7.0...) My servers run Debian. -------------- 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 seg at haxxed.com Mon Jan 9 02:42:45 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 08 Jan 2006 20:42:45 -0600 Subject: edit root alias when installing the OS In-Reply-To: <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> <1136674356.23159.2.camel@hamburger.booze> <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> Message-ID: <1136774566.18058.23.camel@localhost.localdomain> On Sun, 2006-01-08 at 13:21 +1030, n0dalus wrote: > If there are admins that you can't trust 100% with the root password, > you shouldn't be giving them sudo access either (unless you really > tighten down sudoers and deny-by-default, which probably won't come as > a default configuration). You use sudo because you can then revoke access to individual admins. If everyone knows the root password, the only way to revoke access is to change the root password. Then you have to inform all the other admins. And if the root password is leaked? How do you know who leaked it? Who do you fire? You may never know. With sudo, you'll know who's password was leaked or cracked. A multiple admin scenario is exactly why sudo exists. > Weak passwords are not sudo's fault, but statistically the more users > in sudoers the easier it becomes to get root access. It doesn't matter > how strong the passwords are. How many admins are you expecting here? The more admins you have, the more sudo becomes preferable due to the above problem. > Putting users by default into an > allow-everything sudoers is weakening one of UNIX's most effective > layers of security. Wait, which one is that? Traditional unix's all-or-nothing approach to security is probably its biggest design flaw. (Hence why SELinux exists.) -------------- 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 n0dalus+redhat at gmail.com Mon Jan 9 03:22:44 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Mon, 9 Jan 2006 13:52:44 +1030 Subject: edit root alias when installing the OS In-Reply-To: <20060108112942.cbfe7def.Tommy.Reynolds@MegaCoder.com> References: <1136149140.3230.5.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> <1136674356.23159.2.camel@hamburger.booze> <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> <20060108112942.cbfe7def.Tommy.Reynolds@MegaCoder.com> Message-ID: <6280325c0601081922s7b6c2c1fn2dab75f502a40256@mail.gmail.com> On 1/9/06, Tommy Reynolds wrote: > Uttered n0dalus , spake thus: > > > Why should we cripple people's ability to administrate their systems > > by taking away the root password? If I had to prepend all my commands > > with 'sudo' and half of my paths with '/sbin' I'd quickly get > > frustrated and give root a password. > > So put "/sbin" on your normal path. > > Well, doing a significant amount of work as root does seem to justify > sudo'ing into the root account: > > $ sudo su - > > But the proper /etc/sudoers entry would let only _your_ account run > _only_ that program and require _your_ password to do it. At least > you'd get an audit trail entry as you entered the superuser realm. > With a root login, you get *nothing*. Was that a hostile root login? > You can only hope not. As said earlier in the thread, it's really easy to make a hostile operation seem completely innocent in the audit trail -- not to mention how easy it is to delete the audit trail entirely, or re-setup sudoers. Audit trails don't help you when it comes to anything malicious or hostile. It only helps you work out what commands you ran. > > > Just because admins know the root password doesn't mean any malware > > that manages to sneak on does too. Putting all the users in sudoers > > means that malware only needs to get a user password for root access, > > which is usually much easier than obtaining the root password. > > Not really. To break into a UNIX system, I need to have two items: a > valid account name, and a valid password. With the "root" account, > I'm halfway there already. We are talking about where the malware is already on the computer. In which case, it knows at least one other username and probably all the usernames on the computer. Maybe it even knows which users can sudo. Let's count the number of people that know the root password -- let's say 5. Let's count the number of users that might be able to sudo -- lets say 10. Now let's count the number of family/friends of those users (and websites, considering that many users use their user password for website signups) who know the sudoers' passwords: much more than the 5 who know the root password. Social engineering, password cracking and malicious put-your-password-here prompts all make it magnitudes easier to get root access as more users are put in sudoers. If Gmail used a Firefox exploit to send me some malware on Linux, there's a good chance that if they try the password I used to signup they could get root access on my machine using sudo (if I was in sudoers, and used the same password as my user account). Yes sudo shouldn't be blamed for any of this, but the fact remains that the more users that can sudo, the better chance malware has of getting root access. > > > Weak passwords are not sudo's fault, but statistically the more users > > in sudoers the easier it becomes to get root access. It doesn't matter > > how strong the passwords are. > > The idea is not to C3 secure the whole environment (that's another > show ;-) but to help Aunt Minerva (substitute your favorite > non-technical user name here) get help when something gets bungled > while in superuser mode. At least there is an audit trail so the > help desk can get a glimmer of what was actually done rather than what > the semi-inept user thought was being done. Aunt Minerva should not be doing anything as superuser. On occasion she might be asked to enter the root password into a graphical dialogue to setup something, but that should be all. If a user can't handle su -, they shouldn't be using sudo either. Maybe Fedora should come setup with bash so it logs all commands ran as root -- this would be more useful for tech support than the sudo audit trail. > The goal, at least of my original posting, was to encourage newbies > to use the sudo method for those times they need superuser privilege. > Reading the sudo(1) man page gives pause even to seasoned admins and > probably drives newbies back screaming to Google.com for another > command. Yet, sudo(1) is probably the safest was to superuser command > line access for casual admin activity. Thus the need to gently steer > newbies to sudo(1) for, maybe, some set of common root commands. > > Sudo(1) is not intended to outlaw su(8) for real admins and power > users. > > As we try to promote Linux on the desktop and in the home, depending > on more casual admins, we need more audit trails, not fewer, so the > savy among us can help when disaster ensues. Sudo(1) or su(8) issues > aside, disaster _will_ ensue, so why not try for the most well-paved > path? > Let's pave the path for su as well then. ~/.bash_history only stores a small number of lines by default, but perhaps something else could be setup to give better logging of commands run as root. If all commands ran from bash as root were logged somewhere, would that be sufficient to make su acceptable for casual administration? Is this a solution that everyone can agree on? I am all for having more audit trails, but if we can have that without weaking the security of Fedora by default, then I think that's a better solution. Sudo is still useful for multi-admin situations, but really only when sudoers is setup with strict permissions. Nobody should be put in an allow-everything sudoers by default. n0dalus. From wtogami at redhat.com Mon Jan 9 03:42:35 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 08 Jan 2006 22:42:35 -0500 Subject: Help Needed: libdv Message-ID: <43C1DBAB.5040100@redhat.com> libdv has not had a successful build or version upgrade since March 2005 for FC4. We have higher priority things to work on elsewhere in the distro, so your assistance is needed to help get this fixed in FC5. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176909 build failure log of current version https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147311 newer version fails https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146596 another libdv problem that should be solved Warren Togami wtogami at redhat.com From sundaram at redhat.com Mon Jan 9 06:43:38 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 09 Jan 2006 12:13:38 +0530 Subject: dependency quirks Message-ID: <43C2061A.9080208@redhat.com> Hi yum groupremove "GNOME Desktop Environment" on rawhide shows system-config-display, system-config-control(Fedora Extras package) and system-config-boot in the dependency list. Yum remove system-config-display lists firstboot as a dependency. This seems reversed. Also yum remove metacity lists firstboot and s-c-d as a dependency. Isnt this quirky?. I might very well be using s-c-* without using GNOME. # yum groupremove "GNOME Desktop Environment" Loading "installonlyn" plugin Setting up Group Process Setting up repositories Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package gtk-engines.i386 1:0.12-7.1 set to be erased ---> Package gnome-audio.noarch 0:2.0.0-3.1 set to be erased ---> Package control-center.i386 1:2.13.3-2 set to be erased ---> Package gedit.i386 1:2.13.1-1 set to be erased ---> Package evince.i386 0:0.4.0-3.1 set to be erased ---> Package gthumb.i386 0:2.7.2-1 set to be erased ---> Package NetworkManager-gnome.i386 0:0.5.1-5.1 set to be erased ---> Package gnome-user-share.i386 0:0.9-1.1 set to be erased ---> Package gnome-applets.i386 1:2.13.1-4 set to be erased ---> Package control-center.i386 1:2.13.4-1 set to be erased ---> Package gnome-media.i386 0:2.12.0-3.1 set to be erased ---> Package gnome-themes.noarch 0:2.13.2-3 set to be erased ---> Package gnome-volume-manager.i386 0:1.5.7-2 set to be erased ---> Package at-spi.i386 0:1.6.6-2.1 set to be erased ---> Package gnome-system-monitor.i386 0:2.13.3-2 set to be erased ---> Package gimp-print-utils.i386 0:4.2.7-15 set to be erased ---> Package vino.i386 0:2.12.0-2.1 set to be erased ---> Package hwbrowser.noarch 0:0.24-1.1 set to be erased ---> Package gnome-session.i386 0:2.12.0-5 set to be erased ---> Package gnopernicus.i386 0:1.0.0-1 set to be erased ---> Package nautilus-sendto.i386 0:0.4-6 set to be erased ---> Package gnome-vfs2-smb.i386 0:2.13.3-1 set to be erased ---> Package gthumb.i386 0:2.7.1-1.1 set to be erased ---> Package desktop-printing.i386 0:0.19-4.1 set to be erased ---> Package gnome-user-docs.noarch 0:2.8.1-2.1 set to be erased ---> Package metacity.i386 0:2.13.8-1 set to be erased ---> Package file-roller.i386 0:2.13.3-1 set to be erased ---> Package gnome-netstatus.i386 0:2.12.0-3.1 set to be erased ---> Package gnome-applets.i386 1:2.13.1-2 set to be erased ---> Package gnome-system-monitor.i386 0:2.13.4-1 set to be erased ---> Package gnome-utils.i386 1:2.13.4-1 set to be erased ---> Package gnome-panel.i386 0:2.13.4-1 set to be erased ---> Package gnome-screensaver.i386 0:0.0.23-3 set to be erased ---> Package gok.i386 0:1.0.5-6.1 set to be erased ---> Package nautilus.i386 0:2.13.3-1 set to be erased ---> Package gnome-pilot.i386 0:2.0.13-7.fc5.1 set to be erased ---> Package gnome-mag.i386 0:0.12.2-2.1 set to be erased ---> Package gnome-kerberos.i386 0:0.3.3-2.1 set to be erased ---> Package gnome-terminal.i386 0:2.13.0-2 set to be erased ---> Package yelp.i386 0:2.13.2-2 set to be erased ---> Package gtk2-engines.i386 0:2.7.2-1 set to be erased ---> Package gnome-panel.i386 0:2.13.3-3 set to be erased --> Running transaction check Setting up repositories Reading repository metadata in from local files --> Processing Dependency: metacity for package: system-config-display --> Processing Dependency: libgnome-media-profiles.so.0 for package: sound-juicer --> Processing Dependency: at-spi >= 1.0.1 for package: libgail-gnome --> Processing Dependency: libnautilus-extension.so.1 for package: nautilus-cd-burner --> Processing Dependency: gnome-media >= 2.9.90 for package: sound-juicer --> Processing Dependency: libnautilus-extension.so.1 for package: totem --> Processing Dependency: gnome-media >= 2.9.90 for package: sound-juicer --> Processing Dependency: metacity for package: firstboot --> Processing Dependency: libspi.so.0 for package: libgail-gnome --> Processing Dependency: libgnome-media-profiles.so.0 for package: sound-juicer --> Processing Dependency: libpanel-applet-2.so.0 for package: libgail-gnome --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package sound-juicer.i386 0:2.13.1-3 set to be erased ---> Package totem.i386 0:1.3.0-3 set to be erased ---> Package sound-juicer.i386 0:2.13.1-2.1 set to be erased ---> Package libgail-gnome.i386 0:1.1.2-1.1 set to be erased ---> Package system-config-display.noarch 0:1.0.33-1.1 set to be erased ---> Package nautilus-cd-burner.i386 0:2.13.3-1 set to be erased ---> Package firstboot.noarch 0:1.3.55-1.1 set to be erased --> Running transaction check --> Processing Dependency: libnautilus-burn.so.3 for package: rhythmbox --> Processing Dependency: firstboot for package: system-config-control --> Processing Dependency: firstboot for package: system-config-boot --> Processing Dependency: libtotem-plparser.so.0 for package: rhythmbox --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package system-config-control.noarch 0:1.0-3.fc5 set to be erased ---> Package system-config-boot.i386 0:0.2.11-1.1 set to be erased ---> Package rhythmbox.i386 0:0.9.2-4 set to be erased --> Running transaction check Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: NetworkManager-gnome i386 0.5.1-5.1 installed 287 k at-spi i386 1.6.6-2.1 installed 747 k control-center i386 1:2.13.3-2 installed 7.0 M control-center i386 1:2.13.4-1 installed 7.1 M desktop-printing i386 0.19-4.1 installed 260 k evince i386 0.4.0-3.1 installed 1.9 M file-roller i386 2.13.3-1 installed 3.1 M gedit i386 1:2.13.1-1 installed 12 M gimp-print-utils i386 4.2.7-15 installed 35 k gnome-applets i386 1:2.13.1-4 installed 31 M gnome-applets i386 1:2.13.1-2 installed 31 M gnome-audio noarch 2.0.0-3.1 installed 1.4 M gnome-kerberos i386 0.3.3-2.1 installed 74 k gnome-mag i386 0.12.2-2.1 installed 218 k gnome-media i386 2.12.0-3.1 installed 5.4 M gnome-netstatus i386 2.12.0-3.1 installed 971 k gnome-panel i386 2.13.4-1 installed 9.0 M gnome-panel i386 2.13.3-3 installed 8.9 M gnome-pilot i386 2.0.13-7.fc5.1 installed 1.7 M gnome-screensaver i386 0.0.23-3 installed 3.3 M gnome-session i386 2.12.0-5 installed 1.2 M gnome-system-monitor i386 2.13.3-2 installed 1.7 M gnome-system-monitor i386 2.13.4-1 installed 1.6 M gnome-terminal i386 2.13.0-2 installed 7.3 M gnome-themes noarch 2.13.2-3 installed 3.2 M gnome-user-docs noarch 2.8.1-2.1 installed 1.9 M gnome-user-share i386 0.9-1.1 installed 79 k gnome-utils i386 1:2.13.4-1 installed 14 M gnome-vfs2-smb i386 2.13.3-1 installed 26 k gnome-volume-manager i386 1.5.7-2 installed 1.4 M gnopernicus i386 1.0.0-1 installed 6.2 M gok i386 1.0.5-6.1 installed 6.9 M gthumb i386 2.7.2-1 installed 5.5 M gthumb i386 2.7.1-1.1 installed 5.4 M gtk-engines i386 1:0.12-7.1 installed 1.5 M gtk2-engines i386 2.7.2-1 installed 658 k hwbrowser noarch 0.24-1.1 installed 247 k metacity i386 2.13.8-1 installed 8.7 M nautilus i386 2.13.3-1 installed 11 M nautilus-sendto i386 0.4-6 installed 144 k vino i386 2.12.0-2.1 installed 1.1 M yelp i386 2.13.2-2 installed 1.2 M Removing for dependencies: firstboot noarch 1.3.55-1.1 installed 837 k libgail-gnome i386 1.1.2-1.1 installed 60 k nautilus-cd-burner i386 2.13.3-1 installed 1.3 M rhythmbox i386 0.9.2-4 installed 4.1 M sound-juicer i386 2.13.1-3 installed 1.4 M sound-juicer i386 2.13.1-2.1 installed 1.4 M system-config-boot i386 0.2.11-1.1 installed 112 k system-config-control noarch 1.0-3.fc5 installed 189 k system-config-display noarch 1.0.33-1.1 installed 600 k totem i386 1.3.0-3 installed 3.8 M Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 52 Package(s) Total download size: 0 Is this ok [y/N]: # yum remove system-config-display Loading "installonlyn" plugin Setting up Remove Process Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package system-config-display.noarch 0:1.0.33-1.1 set to be erased --> Running transaction check Setting up repositories Reading repository metadata in from local files --> Processing Dependency: system-config-display for package: firstboot --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package firstboot.noarch 0:1.3.55-1.1 set to be erased --> Running transaction check --> Processing Dependency: firstboot for package: system-config-control --> Processing Dependency: firstboot for package: system-config-boot --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package system-config-control.noarch 0:1.0-3.fc5 set to be erased ---> Package system-config-boot.i386 0:0.2.11-1.1 set to be erased --> Running transaction check Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: system-config-display noarch 1.0.33-1.1 installed 600 k Removing for dependencies: firstboot noarch 1.3.55-1.1 installed 837 k system-config-boot i386 0.2.11-1.1 installed 112 k system-config-control noarch 1.0-3.fc5 installed 189 k Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 4 Package(s) Total download size: 0 Is this ok [y/N]: # yum remove metacity Loading "installonlyn" plugin Setting up Remove Process Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package metacity.i386 0:2.13.8-1 set to be erased --> Running transaction check Setting up repositories Reading repository metadata in from local files --> Processing Dependency: metacity for package: system-config-display --> Processing Dependency: metacity for package: firstboot --> Processing Dependency: libmetacity-private.so.0 for package: control-center --> Processing Dependency: libmetacity-private.so.0 for package: control-center --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package control-center.i386 1:2.13.4-1 set to be erased ---> Package control-center.i386 1:2.13.3-2 set to be erased ---> Package system-config-display.noarch 0:1.0.33-1.1 set to be erased ---> Package firstboot.noarch 0:1.3.55-1.1 set to be erased --> Running transaction check --> Processing Dependency: firstboot for package: system-config-control --> Processing Dependency: control-center for package: gnome-session --> Processing Dependency: firstboot for package: system-config-boot --> Processing Dependency: control-center >= 2.0 for package: gnome-volume-manager --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package system-config-boot.i386 0:0.2.11-1.1 set to be erased ---> Package gnome-session.i386 0:2.12.0-5 set to be erased ---> Package gnome-volume-manager.i386 0:1.5.7-2 set to be erased ---> Package system-config-control.noarch 0:1.0-3.fc5 set to be erased --> Running transaction check Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Removing: metacity i386 2.13.8-1 installed 8.7 M Removing for dependencies: control-center i386 1:2.13.4-1 installed 7.1 M control-center i386 1:2.13.3-2 installed 7.0 M firstboot noarch 1.3.55-1.1 installed 837 k gnome-session i386 2.12.0-5 installed 1.2 M gnome-volume-manager i386 1.5.7-2 installed 1.4 M system-config-boot i386 0.2.11-1.1 installed 112 k system-config-control noarch 1.0-3.fc5 installed 189 k system-config-display noarch 1.0.33-1.1 installed 600 k Transaction Summary ============================================================================= Install 0 Package(s) Update 0 Package(s) Remove 9 Package(s) Total download size: 0 Is this ok [y/N]: -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From buildsys at redhat.com Mon Jan 9 08:02:11 2006 From: buildsys at redhat.com (Build System) Date: Mon, 9 Jan 2006 03:02:11 -0500 Subject: rawhide report: 20060109 changes Message-ID: <200601090802.k0982Bhq011516@porkchop.devel.redhat.com> Updated Packages: gedit-1:2.13.1-2 ---------------- * Sun Jan 08 2006 Dan Williams - 1:2.13.1-2 - Fix up and re-enable persistent file selector size patch yum-2.5.1-1 ----------- * Sun Jan 08 2006 Jeremy Katz - 2.5.1-1 - seth loves me and made a 2.5.1 release. so no cvs snap for you! * Sun Jan 08 2006 Jeremy Katz - 2.5.1-0.20060108 - update to CVS snap Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5smp jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 openhpi - 2.2.1-1.i386 requires libnetsnmp.so.9 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 openhpi - 2.2.1-1.ppc requires libnetsnmp.so.9 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) openhpi - 2.2.1-1.ppc64 requires libnetsnmp.so.9()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 openhpi - 2.2.1-1.s390 requires libnetsnmp.so.9 Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) openhpi - 2.2.1-1.s390x requires libnetsnmp.so.9()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) openhpi - 2.2.1-1.x86_64 requires libnetsnmp.so.9()(64bit) From kmaraas at broadpark.no Mon Jan 9 08:40:42 2006 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Mon, 09 Jan 2006 09:40:42 +0100 Subject: cairo fail gcc4 build In-Reply-To: <1136726533.3041.12.camel@T7.Linux> References: <43C102D6.4070909@gmail.com> <1136726533.3041.12.camel@T7.Linux> Message-ID: <1136796042.2578.6.camel@localhost.localdomain> s?n, 08,.01.2006 kl. 13.22 +0000, skrev Paul F. Johnson: > Hi, > > On Sun, 2006-01-08 at 13:17 +0100, Tomo Vuckovic wrote: > > > Attached is a patch that fixes. > > Shouldn't this be in bugzilla? Actually this and the long standing vte > bug means that mono cannot be fully built? Secret agenda anyone ;-p > Which long standing vte bug is that? And is it filed upstream? Cheers Kjartan From paul at all-the-johnsons.co.uk Mon Jan 9 09:11:30 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Mon, 09 Jan 2006 09:11:30 +0000 Subject: cairo fail gcc4 build In-Reply-To: <1136796042.2578.6.camel@localhost.localdomain> References: <43C102D6.4070909@gmail.com> <1136726533.3041.12.camel@T7.Linux> <1136796042.2578.6.camel@localhost.localdomain> Message-ID: <1136797891.3173.4.camel@mrwibble.mrwobble> Hi, > > > Shouldn't this be in bugzilla? Actually this and the long standing vte > > bug means that mono cannot be fully built? Secret agenda anyone ;-p > > > Which long standing vte bug is that? And is it filed upstream? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176346 No signs of anything upstream. I personally would have thought this to be more of a packaging fault rather than vte. It has been reported upstream http://bugzilla.gnome.org/show_bug.cgi?id=325030 TTFN Paul -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From sundaram at redhat.com Mon Jan 9 11:15:18 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 09 Jan 2006 16:45:18 +0530 Subject: system-config-sshd ? In-Reply-To: <42D9E648.20302@flashmail.com> References: <42D7ED99.8050506@flashmail.com> <42D9CAB0.2060901@redhat.com> <42D9D731.8020703@flashmail.com> <42D9DA1A.1050500@redhat.com> <42D9DF05.6010007@flashmail.com> <42D9DFEC.50407@redhat.com> <42D9E648.20302@flashmail.com> Message-ID: <43C245C6.8080201@redhat.com> Arthur Pemberton wrote: > Rahul Sundaram wrote: > >> Hi >> >>>>> >>>> Other system configuration tools are more suited to do the basic >>>> functionality and not expose a lot of details. You could do it in a >>>> more comprehensive way but the UI should be designed to do the >>>> basic things in an easy way first >>> >>> >>> >>> >>> Care to present me with some easily observed examples so that I >>> could better apply what you're suggesting to my problem? >> >> >> >> Sure. system-config-httpd only exposes basic functionality for >> example. GUI applications shouldnt be designed with the aim to expose >> all the configuration options but as task based systems. Figuring out >> what options fit into which task group would be a good idea. Try >> create some mockups using glade. >> regards >> Rahul >> > Will do. Any followups on this one? -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From fedora at wir-sind-cool.org Mon Jan 9 11:37:23 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 9 Jan 2006 12:37:23 +0100 Subject: More mass rebuilds for GCC In-Reply-To: <1134891796.5262.19.camel@ender> References: <1134891796.5262.19.camel@ender> Message-ID: <20060109123723.641198d7.fedora@wir-sind-cool.org> On Sat, 17 Dec 2005 23:43:16 -0800, Jesse Keating wrote: > As you'll notice, there will be lots more packages bumped for the rebase > to gcc. Most completed today, but we'll be working through a list of > failures over the next couple days. Things will still be in a bit of > flux, but we're working on it. > > Java is still being worked on too. Getting the java stack built with > gcj is a great accomplishment and I really respect our java and gcj team > for putting in the work to further the free java. Please bare with us > as we finalize the development changes necessary to accomplish this > task. Does the new GCC introduce any run-time/ABI breakage which requires packages in Fedora Extras Development to be rebuilt? Or does it only reveal problematic source code? From pbrobinson at gmail.com Mon Jan 9 11:57:15 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 9 Jan 2006 11:57:15 +0000 Subject: mkinitrd problems with recent rawhide kernels Message-ID: <5256d0b0601090357q4c1ee3e5i3cbe0aa8dcecaad6@mail.gmail.com> Hi All, Is anyone else seeing issues with updating to the latest 2.6.15-1.1826 series of kernels. I find it gets stuck in the post install script and when I run the mkinitrd script manually it just hangs indefinately (like when doing a yum update or manual rpm install). This is on a Dell D600 laptop. Cheers, Pete From pbrobinson at gmail.com Mon Jan 9 11:38:28 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 9 Jan 2006 11:38:28 +0000 Subject: More mass rebuilds for GCC In-Reply-To: <20060109123723.641198d7.fedora@wir-sind-cool.org> References: <1134891796.5262.19.camel@ender> <20060109123723.641198d7.fedora@wir-sind-cool.org> Message-ID: <5256d0b0601090338j65ebeee2v1faf2f23ac7c346f@mail.gmail.com> On 1/9/06, Michael Schwendt wrote: > On Sat, 17 Dec 2005 23:43:16 -0800, Jesse Keating wrote: > > > As you'll notice, there will be lots more packages bumped for the rebase > > to gcc. Most completed today, but we'll be working through a list of > > failures over the next couple days. Things will still be in a bit of > > flux, but we're working on it. > > > > Java is still being worked on too. Getting the java stack built with > > gcj is a great accomplishment and I really respect our java and gcj team > > for putting in the work to further the free java. Please bare with us > > as we finalize the development changes necessary to accomplish this > > task. > > Does the new GCC introduce any run-time/ABI breakage which requires > packages in Fedora Extras Development to be rebuilt? Or does it only > reveal problematic source code? I think all the extras need to be rebuilt for this. I know seahorse for one needs it (and may need some fixes). Pete From walovaton at yahoo.com.mx Mon Jan 9 14:34:11 2006 From: walovaton at yahoo.com.mx (William Lovaton) Date: Mon, 09 Jan 2006 09:34:11 -0500 Subject: USB storage question (was Re: CD Eject) In-Reply-To: <43BE440F.60900@mesias.co.uk> References: <1cef3e950601050604g484b26cdo2b27de665fc9d6c2@mail.gmail.com> <1136488717.22333.42.camel@remedyz.boston.redhat.com> <43BE440F.60900@mesias.co.uk> Message-ID: <1136817251.2197.3.camel@athlon2000> Camilo, I am not really sure if it is the same problem but I guess you might want to take a look at this bug report: [] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144551 And if it is relevant to you, please drop a comment. Cheers, -William El vie, 06-01-2006 a las 10:18 +0000, Cam escribi??: > Hi > > > First, never yank a mounted USB device. > > Something that has been bothering me for a while, what is responsible > for detecting and mounting USB devices on Fedora? > > The reason I ask is that I'd like to make sure that what I consider > reasonable mount options are used, including noatime and shortname=win95 > (I have a FAT based mp3 player that by default mounts but is unusable > due to the default shortname setting) > > I would like to reconfigure it and if code changes are necessary to > allow configurability then I might still be tempted. So please point me > in the direction of something relevant... > > -Cam > > -- > camilo at mesias.co.uk <-- > __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/ From mpeters at mac.com Mon Jan 9 14:41:42 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 09 Jan 2006 06:41:42 -0800 Subject: edit root alias when installing the OS In-Reply-To: <20060108112942.cbfe7def.Tommy.Reynolds@MegaCoder.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> <1136674356.23159.2.camel@hamburger.booze> <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> <20060108112942.cbfe7def.Tommy.Reynolds@MegaCoder.com> Message-ID: <1136817703.28835.35.camel@locolhost.localdomain> On Sun, 2006-01-08 at 11:29 -0600, Tommy Reynolds wrote: > > The idea is not to C3 secure the whole environment (that's another > show ;-) but to help Aunt Minerva (substitute your favorite > non-technical user name here) get help when something gets bungled > while in superuser mode. Aunt Minerva should not be expected to open a terminal window of any kind - and therefore sudo doesn't help her. From ph18 at cornell.edu Mon Jan 9 14:44:59 2006 From: ph18 at cornell.edu (Paul A Houle) Date: Mon, 09 Jan 2006 09:44:59 -0500 Subject: edit root alias when installing the OS In-Reply-To: <43BEF5CD.9020609@redhat.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> <1136490840.28143.3.camel@localhost> <43BE9A8C.6000703@cornell.edu> <43BEF5CD.9020609@redhat.com> Message-ID: <43C276EB.2000906@cornell.edu> Rahul Sundaram wrote: > > On the contrary, graphical tools can make it easy as well as safe by > designing and limiting the input as well as providing interactive > warnings etc. In theory GUIs can be a good thing. In practice, they suck. It's painful to watch people who use GUIs struggling with interminable menus, file choosers and modal dialog boxes to do simple things that can be done in a few keystrokes in a CLI. Even companies that are famous for producing products that are "easy to use" make products that are horrible: just try making iTunes stop playing music, or see how many images (1500 or so) it takes to make iPhoto start breaking down. At work I've been working with a commercial CMS that is actually pretty good, but has an astonishing number of "dropped a few bits on the floor" errors because of the complexity of the GUI. Even my wife is starting to prefer playing music with bash and ogg123 (it's not hard to play all the tracks on an album in order, for instance.) One big part of the trouble is that there are different orders that people can do things in: the "wizard" strategy of putting a user in a tunnel where they need to make decisions in a particular order and you don't waste their attention with irrelevant choices is one of the best ideas, but you've got to be enable to script out every scenario -- it's a lot of design work. A user-initiative interface might look like a better idea, but the combinatorics of ways users could do things are exponential, making debugging and testing a ball of string that you never get to the end of. People also have a hard time learning GUI interfaces -- it might not be "politically correct" to say, but why else are there 1500 page tomes on how to use Microsoft Word? Unix GUIs are particularly plauged by a mismatch between data structures and the things an application wants to do with them. This is the reason why a decent GUI doesn't exist for Apache configuration after all these years: you can't really map the space of Apache configurations to a GUI in a useful way. A "wizard" for common configurations is easy, but a GUI that handles 90% of what beginners want to do and 10% of what experts want to do is close to useless. To make GUIs work, Unix would have to give up on human-comprehensible configuration files. (Yes, that means XML.) Just the other day I was realizing how hamstrung Firefox is by being based on the open mbox format -- it's not a scalable way of dealing with mailboxes > 500 MB. But that's the road to Opera M2... Storing your mail in a roach motel where you'll never get it out. From mpeters at mac.com Mon Jan 9 14:43:33 2006 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 09 Jan 2006 06:43:33 -0800 Subject: edit root alias when installing the OS In-Reply-To: <1136774566.18058.23.camel@localhost.localdomain> References: <1136149140.3230.5.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <1136443885.9226.13.camel@locolhost.localdomain> <1136491878.20011.14.camel@localhost> <1136517305.2899.19.camel@locolhost.localdomain> <1136674356.23159.2.camel@hamburger.booze> <6280325c0601071851t7f6cd7a8p3aff107ce0e5a6c6@mail.gmail.com> <1136774566.18058.23.camel@localhost.localdomain> Message-ID: <1136817813.28835.36.camel@locolhost.localdomain> On Sun, 2006-01-08 at 20:42 -0600, Callum Lerwick wrote: > > How many admins are you expecting here? The more admins you have, the > more sudo becomes preferable due to the above problem. In which case you should have an admin who sets up sudo for your particular needs - and secure defaults, exactly what Fedora has now. From sundaram at redhat.com Mon Jan 9 14:53:36 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 09 Jan 2006 20:23:36 +0530 Subject: edit root alias when installing the OS In-Reply-To: <43C276EB.2000906@cornell.edu> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> <1136490840.28143.3.camel@localhost> <43BE9A8C.6000703@cornell.edu> <43BEF5CD.9020609@redhat.com> <43C276EB.2000906@cornell.edu> Message-ID: <43C278F0.4040908@redhat.com> Paul A Houle wrote: > Rahul Sundaram wrote: > >> >> On the contrary, graphical tools can make it easy as well as safe by >> designing and limiting the input as well as providing interactive >> warnings etc. > > In theory GUIs can be a good thing. > > In practice, they suck. It's painful to watch people who use > GUIs struggling with interminable menus, file choosers and modal > dialog boxes to do simple things that can be done in a few keystrokes > in a CLI. You are overgeneralizing here. > > To make GUIs work, Unix would have to give up on > human-comprehensible configuration files. (Yes, that means XML.) Many of them have indeed adopted XML but this is not the one true path by any means. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From walovaton at yahoo.com.mx Mon Jan 9 14:35:46 2006 From: walovaton at yahoo.com.mx (William Lovaton) Date: Mon, 09 Jan 2006 09:35:46 -0500 Subject: yum update gone bad today? In-Reply-To: <1136493357.2462.8.camel@aurora.localdomain> References: <1136493357.2462.8.camel@aurora.localdomain> Message-ID: <1136817346.2197.5.camel@athlon2000> I wonder what that file is for... can someone elaborate on that? according to rpm that file belongs to glibc package. Thanks, -William El jue, 05-01-2006 a las 13:35 -0700, Trever L. Adams escribi??: > I had this happen on one machine. Make sure you remove all nisplus > entries from any line that is not commented (#) in /etc/nsswitch.conf. > Note, you do not remove the entire line, you just remove nisplus. > > I had one computer that had this problem and this is what fixed it. IT > was also very interesting. None of the other machines have nisplus > entries. I do not know why one would get it (that was only occassionally > updated) while another didn't and none of the ones that get updated > nearly every day had the problem. > > Trever Adams > > On Thu, 2006-01-05 at 13:10 -0500, sean wrote: > > yum has worked for months. It worked yesterday. Now: > > > > yum update > > Repository development is listed more than once in the > > configuration > > Setting up Update Process > > Setting up repositories > > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/repodata/repomd.xml: > > [Errno 4] IOError: > directory')> > > Trying other mirror. > > Cannot open/read repomd.xml file for repository: development > > failure: repodata/repomd.xml from development: [Errno 256] > > No more mirrors to try. > > Error: failure: repodata/repomd.xml from development: [Errno > > 256] No more mirrors to try. > > > > > > Tried yum-2.5.0-5 and yum-2.4.1-3. Same result. > > > > cat yum.conf > > [main] > > cachedir=/var/cache/yum > > debuglevel=2 > > logfile=/var/log/yum.log > > pkgpolicy=newest > > distroverpkg=fedora-release > > tolerant=1 > > exactarch=0 > > retries=20 > > > > [development] > > name=Fedora Core $releasever - Development Tree > > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64 > > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide > > enabled=1 > > > > > > I can pull up > > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/repodata/repomd.xml > > in firefox. > > > > And it doesn't seem to try the mirrors. > > > > Something changed about yum configuration I've missed? > > > > Any one else seing this? > > > > sean > > > -- > "I don't know how World War III will be fought, but I do know World War > IV will be fought with sticks and stones" -- Einstein > __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/ From sundaram at redhat.com Mon Jan 9 15:44:11 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 09 Jan 2006 21:14:11 +0530 Subject: yum update gone bad today? In-Reply-To: <1136817346.2197.5.camel@athlon2000> References: <1136493357.2462.8.camel@aurora.localdomain> <1136817346.2197.5.camel@athlon2000> Message-ID: <43C284CB.2040906@redhat.com> William Lovaton wrote: >I wonder what that file is for... can someone elaborate on that? >according to rpm that file belongs to glibc package. > >Thanks, > >-William > Name service configuration file. man nssswitch.conf for details. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From pemboa at gmail.com Mon Jan 9 16:25:49 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 9 Jan 2006 10:25:49 -0600 Subject: system-config-sshd ? In-Reply-To: <43C245C6.8080201@redhat.com> References: <42D7ED99.8050506@flashmail.com> <42D9CAB0.2060901@redhat.com> <42D9D731.8020703@flashmail.com> <42D9DA1A.1050500@redhat.com> <42D9DF05.6010007@flashmail.com> <42D9DFEC.50407@redhat.com> <42D9E648.20302@flashmail.com> <43C245C6.8080201@redhat.com> Message-ID: <16de708d0601090825m402a9d5dwf141c23f18fdb747@mail.gmail.com> On 1/9/06, Rahul Sundaram wrote: > > Arthur Pemberton wrote: > > > Rahul Sundaram wrote: > > > >> Hi > >> > >>>>> > >>>> Other system configuration tools are more suited to do the basic > >>>> functionality and not expose a lot of details. You could do it in a > >>>> more comprehensive way but the UI should be designed to do the > >>>> basic things in an easy way first > >>> > >>> > >>> > >>> > >>> Care to present me with some easily observed examples so that I > >>> could better apply what you're suggesting to my problem? > >> > >> > >> > >> Sure. system-config-httpd only exposes basic functionality for > >> example. GUI applications shouldnt be designed with the aim to expose > >> all the configuration options but as task based systems. Figuring out > >> what options fit into which task group would be a good idea. Try > >> create some mockups using glade. > >> regards > >> Rahul > >> > > Will do. > > Any followups on this one? Not just yet, my time has been largely consumed of late. -- > Rahul > > Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Mon Jan 9 17:25:45 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 9 Jan 2006 10:25:45 -0700 Subject: system-config-sshd ? In-Reply-To: <16de708d0601090825m402a9d5dwf141c23f18fdb747@mail.gmail.com> References: <42D7ED99.8050506@flashmail.com> <42D9CAB0.2060901@redhat.com> <42D9D731.8020703@flashmail.com> <42D9DA1A.1050500@redhat.com> <42D9DF05.6010007@flashmail.com> <42D9DFEC.50407@redhat.com> <42D9E648.20302@flashmail.com> <43C245C6.8080201@redhat.com> <16de708d0601090825m402a9d5dwf141c23f18fdb747@mail.gmail.com> Message-ID: <80d7e4090601090925l4861c82ek420f9bb498856d4a@mail.gmail.com> On 1/9/06, Arthur Pemberton wrote: > > > > > > Any followups on this one? > > Not just yet, my time has been largely consumed of late. > I am looking at this myself. My time is also limited so my timeline would be for FC6 (expecting a 6 month release period). The main idea for the GUI would be to turn on/off various security mechanisms to meet various security criteria. It would be command line oriented also so that it can be run from kickstart. > > -- > > Rahul > > > > Fedora Bug Triaging - > http://fedoraproject.org/wiki/BugZappers > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > As a boy I jumped through Windows, as a man I play with Penguins. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- Stephen J Smoogen. CSIRT/Linux System Administrator From ph18 at cornell.edu Mon Jan 9 18:08:39 2006 From: ph18 at cornell.edu (Paul A Houle) Date: Mon, 09 Jan 2006 13:08:39 -0500 Subject: edit root alias when installing the OS In-Reply-To: <43C278F0.4040908@redhat.com> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> <1136490840.28143.3.camel@localhost> <43BE9A8C.6000703@cornell.edu> <43BEF5CD.9020609@redhat.com> <43C276EB.2000906@cornell.edu> <43C278F0.4040908@redhat.com> Message-ID: <43C2A6A7.6060204@cornell.edu> Rahul Sundaram wrote: > You are overgeneralizing here. > You're right. However: (1) GUIs are expensive to develop. A GUI configuration dialog for a system can be an order of magnitude more complex (and expensive to develop) than the system. (2) GUIs face difficult scalability problems. Part of this has to do with HCI issues: one needs a different UI to choose between 10 items, 100 items, 1000 items or 10^6 items. Part of it has to do with data structures: GUIs generally build bulky data structures in RAM, causing swapping problems with modest data sets. Yeah, you can have the data in external memory and use flyweights to display stuff on the screen, but that's trading for another set of performance problems. (3) Partially because of (1) and partially because of organization imperatives (Apple, for instance, wants to use iTunes to push ALAC instead of FLAC), GUIs express an ideology. At best a GUI makes "certain tasks trivial and other tasks difficult", but it's more likely to be "certain tasks trivial and other tasks impossible" or "certain tasks difficult and other tasks impossible" Perhaps things have gotten better in rawhide, but the "firewall configuration" gimmick in RHEL is a classic example of "uselessware". Pretty much every system I run needs to have a few ports punched in the firewall that aren't in the list -- the firewall configuration gimmick never remembers the ports that I've already opened, so I have to keep a list of the ports that I've opened somewhere (or maybe look at the conf file I'm not supposed to change) and enter them all in by hand. It's an example of "for the want of a nail... the kingdom was lost" that often kills GUI apps. The basic issue is that a GUI firewall editor has to support 100% of the functionality I need or coexist with my ability to edit conf files by hand, or it's 100% useless. A GUI app that does 90% of what I need isn't enough if there is no workaround to get the other 10%. >> >> To make GUIs work, Unix would have to give up on >> human-comprehensible configuration files. (Yes, that means XML.) > > Many of them have indeed adopted XML but this is not the one true path > by any means. > I'm not against XML, I'm just saying that XML files don't count as human-comprehensible and editable. Something that's basically a database is another option, but again, other than (arguably) relational databases, those aren't human-comprehensible and editable... You may not really be able to have it the GUI way and the "Unix way" -- that doesn't mean that everyone has to stick to the Unix way. My complaint about GUI gadgets (particularly the one in RHEL/Fedora) is that they "almost work" and never "really work" because of a mismatch between the data structures and the UI model. One way to get a correct application is to make the data structures fit the UI model. There are problems with that, but it's possible to make tools that really work that way. From fedora at wir-sind-cool.org Mon Jan 9 18:50:09 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 9 Jan 2006 19:50:09 +0100 Subject: More mass rebuilds for GCC In-Reply-To: <5256d0b0601090338j65ebeee2v1faf2f23ac7c346f@mail.gmail.com> References: <1134891796.5262.19.camel@ender> <20060109123723.641198d7.fedora@wir-sind-cool.org> <5256d0b0601090338j65ebeee2v1faf2f23ac7c346f@mail.gmail.com> Message-ID: <20060109195009.58f4fb31.fedora@wir-sind-cool.org> On Mon, 9 Jan 2006 11:38:28 +0000, Peter Robinson wrote: > On 1/9/06, Michael Schwendt wrote: > > On Sat, 17 Dec 2005 23:43:16 -0800, Jesse Keating wrote: > > > > > As you'll notice, there will be lots more packages bumped for the rebase > > > to gcc. Most completed today, but we'll be working through a list of > > > failures over the next couple days. Things will still be in a bit of > > > flux, but we're working on it. > > > > > > Java is still being worked on too. Getting the java stack built with > > > gcj is a great accomplishment and I really respect our java and gcj team > > > for putting in the work to further the free java. Please bare with us > > > as we finalize the development changes necessary to accomplish this > > > task. > > > > Does the new GCC introduce any run-time/ABI breakage which requires > > packages in Fedora Extras Development to be rebuilt? Or does it only > > reveal problematic source code? > > I think all the extras need to be rebuilt for this. I know seahorse > for one needs it (and may need some fixes). AFAIK, seahorse was affected by SONAME changes in some of its dependencies, which made a rebuild necessary. That was a change not related to the GCC upgrade. My question is not about ordinary breakage through upgrades of dependencies. From fedora at adslpipe.co.uk Mon Jan 9 20:04:17 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Mon, 09 Jan 2006 20:04:17 +0000 Subject: edit root alias when installing the OS In-Reply-To: <43C276EB.2000906@cornell.edu> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> <1136490840.28143.3.camel@localhost> <43BE9A8C.6000703@cornell.edu><43BEF5CD.9020609@redhat.com> <43C276EB.2000906@cornell.edu> Message-ID: <43C2C1C1.7060000@adslpipe.co.uk> Paul A Houle wrote: > In theory GUIs can be a good thing. > In practice, they suck. It's painful to watch people who use GUIs struggling Yes, but most end-users "wouldn't dare" use a terminal window, and would be absolutely lost if you stuck them in-front of one, at least they feel they can hunt around and "have a go" using a GUI ... From kevinverma at gmail.com Mon Jan 9 20:35:48 2006 From: kevinverma at gmail.com (Kevin Verma) Date: Tue, 10 Jan 2006 02:05:48 +0530 Subject: testing PCMCIA setup under FC5, for Sierra Aircard555 CMDA modem (url's updated) In-Reply-To: <20060108220410.GA29800@dominikbrodowski.de> References: <20060108220410.GA29800@dominikbrodowski.de> Message-ID: Thanks very much for your input, I shall respond soon as it is tested out, Cheers, On 1/9/06, Dominik Brodowski wrote: > Hi, > > On Mon, Dec 26, 2005 at 01:08:27PM +0530, Kevin Verma wrote: > > After patching (as on blog_url above) the serial_cs.c, I noticed > > that this PCMCIA device reports different manufacture_id on FC4 > > and FC5, further I noticed the same is happening on FC5 box > > before and after manual firmware loading as below in command > > line snippet. > > > > Before you look into the snippet below I will also like to point > > out that confused about different manufacture_id reporting I > > re-patched the serial_cs.c and below is what is being used for > > the snippet bellow, here: > > +PCMCIA_DEVICE_CIS_MANF_CARD(0x013f, 0xa555, > > "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem */ > > Oh, they change the MANF_ID in the CIS "firmware" "update"... This is why we > need two lines in serial_cs to handle it: > > diff --git a/drivers/serial/serial_cs.c b/drivers/serial/serial_cs.c > index 96969cb..c303336 100644 > --- a/drivers/serial/serial_cs.c > +++ b/drivers/serial/serial_cs.c > @@ -785,6 +785,8 @@ static struct pcmcia_device_id serial_id > PCMCIA_MFC_DEVICE_CIS_MANF_CARD(1, 0x0101, 0x0035, "3CXEM556.cis"), > PCMCIA_MFC_DEVICE_CIS_MANF_CARD(1, 0x0101, 0x003d, "3CXEM556.cis"), > PCMCIA_DEVICE_CIS_MANF_CARD(0x0192, 0x0710, "SW_7xx_SER.cis"), /* Sierra Wireless AC710/AC750 GPRS Network Adapter R1 */ > + PCMCIA_DEVICE_CIS_MANF_CARD(0x0192, 0xa555, "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem -- pre update */ > + PCMCIA_DEVICE_CIS_MANF_CARD(0x013f, 0xa555, "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem -- post update */ > PCMCIA_DEVICE_CIS_PROD_ID12("MultiTech", "PCMCIA 56K DataFax", 0x842047ee, 0xc2efcf03, "MT5634ZLX.cis"), > PCMCIA_DEVICE_CIS_PROD_ID12("ADVANTECH", "COMpad-32/85B-4", 0x96913a85, 0xcec8f102, "COMpad4.cis"), > PCMCIA_DEVICE_CIS_PROD_ID123("ADVANTECH", "COMpad-32/85", "1.0", 0x96913a85, 0x8fbe92ae, 0x0877b627, "COMpad2.cis"), > > > > > Could you test this patch, please? -- whether the CIS update is loaded > automagically then and whether it works "out of the box" then? > > Thanks! > > Dominik > From saddateh at gmail.com Mon Jan 9 20:45:23 2006 From: saddateh at gmail.com (Sadda Teh) Date: Mon, 9 Jan 2006 15:45:23 -0500 Subject: Where's the NetworkManger applet in rawhide? Message-ID: Hi, is it just me or is the NetworkManager applet missing in rawhide? I even re-installed NetworkManager-gnome and still I can't find NetworkManagerInfo on my system. What am I missing here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnp at redhat.com Mon Jan 9 20:53:28 2006 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 09 Jan 2006 15:53:28 -0500 Subject: Where's the NetworkManger applet in rawhide? In-Reply-To: References: Message-ID: <1136840009.2774.19.camel@remedyz.boston.redhat.com> It is called nm-applet now. On Mon, 2006-01-09 at 15:45 -0500, Sadda Teh wrote: > Hi, is it just me or is the NetworkManager applet missing in rawhide? > I even re-installed NetworkManager-gnome and still I can't find > NetworkManagerInfo on my system. What am I missing here? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- John (J5) Palmieri From pub at goldshmidt.org Mon Jan 9 20:27:05 2006 From: pub at goldshmidt.org (Oleg Goldshmidt) Date: Mon, 09 Jan 2006 22:27:05 +0200 Subject: filelists.xml.gz: [Errno -1] Metadata file does not match checksum Message-ID: Hi, Today I am getting the following error when running "yum update" on FC4 x86_64: filelists.xml.gz 100% |=========================| 3.0 MB 00:23 http://mirror.linux.duke.edu/pub/fedora/linux/core/updates/4/x86_64/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. - this is for *all* mirrors yum tries. Any ideas? Is the file corrupted and propagated to all the mirrors? Is it a screwed-up configuration on my end (I have not tinkered with it, actually)? Googling for the error message did not yield anything. What can I check? -- Oleg Goldshmidt | pub at NOSPAM.goldshmidt.org | http://www.goldshmidt.org From pub at goldshmidt.org Mon Jan 9 21:38:22 2006 From: pub at goldshmidt.org (Oleg Goldshmidt) Date: Mon, 09 Jan 2006 23:38:22 +0200 Subject: filelists.xml.gz: [Errno -1] Metadata file does not match checksum In-Reply-To: References: Message-ID: Oleg Goldshmidt writes: > Hi, > > Today I am getting the following error when running "yum update" on > FC4 x86_64: > > filelists.xml.gz 100% |=========================| 3.0 MB 00:23 > http://mirror.linux.duke.edu/pub/fedora/linux/core/updates/4/x86_64/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum > Trying other mirror. > > - this is for *all* mirrors yum tries. Any ideas? Is the file > corrupted and propagated to all the mirrors? Is it a screwed-up > configuration on my end (I have not tinkered with it, actually)? > > Googling for the error message did not yield anything. What can I > check? Eh, it seems to have gone away after "yum clean all" - sorry for the trouble. -- Oleg Goldshmidt | pub at NOSPAM.goldshmidt.org | http://www.goldshmidt.org From jspaleta at gmail.com Mon Jan 9 22:11:59 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 9 Jan 2006 17:11:59 -0500 Subject: filelists.xml.gz: [Errno -1] Metadata file does not match checksum In-Reply-To: References: Message-ID: <604aa7910601091411v4695f25ve88e131647a4361b@mail.gmail.com> On 1/9/06, Oleg Goldshmidt wrote: > Eh, it seems to have gone away after "yum clean all" - sorry for the > trouble. next time you see this happen, before you reach for a "clean all" solution, see if "clean metadata" is enough to solve the problem. Depending on when the metadata cookie was generated in your cache and your cache expiration settings, you can get into a situation where all the mirrors have updated their metadata and your local metadata cache is out of sync with all available mirrors. This is difficult to reproduce and greatly depends on the timing of mirror syncing versus your metadata cache creation and expiration. -jef From pub at goldshmidt.org Mon Jan 9 22:25:31 2006 From: pub at goldshmidt.org (Oleg Goldshmidt) Date: Tue, 10 Jan 2006 00:25:31 +0200 Subject: filelists.xml.gz: [Errno -1] Metadata file does not match checksum In-Reply-To: <604aa7910601091411v4695f25ve88e131647a4361b@mail.gmail.com> References: <604aa7910601091411v4695f25ve88e131647a4361b@mail.gmail.com> Message-ID: Jeff Spaleta writes: > next time you see this happen, before you reach for a "clean all" > solution, see if "clean metadata" is enough to solve the problem. Hmm, didn't know about this one. It appears in the synopsis in the man page, but not in the CLEAN section. Live and learn... Thanks, -- Oleg Goldshmidt | pub at NOSPAM.goldshmidt.org | http://www.goldshmidt.org From seg at haxxed.com Mon Jan 9 23:31:40 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 09 Jan 2006 17:31:40 -0600 Subject: edit root alias when installing the OS In-Reply-To: <43C276EB.2000906@cornell.edu> References: <1136149140.3230.5.camel@rivendell.home.local> <200601011451.42702.jarod@wilsonet.com> <1136166695.2828.8.camel@rivendell.home.local> <200601021338.00925.jarod@wilsonet.com> <1136349270.3368.19.camel@rivendell.home.local> <1136378912.9226.9.camel@locolhost.localdomain> <16de708d0601041200g7f05113fm7d9ee6c4ba67181c@mail.gmail.com> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> <1136490840.28143.3.camel@localhost> <43BE9A8C.6000703@cornell.edu> <43BEF5CD.9020609@redhat.com> <43C276EB.2000906@cornell.edu> Message-ID: <1136849501.24474.10.camel@localhost.localdomain> On Mon, 2006-01-09 at 09:44 -0500, Paul A Houle wrote: > To make GUIs work, Unix would have to give up on > human-comprehensible configuration files. (Yes, that means XML.) Complete and total horse hockey. The route Fedora has gone with system-config-* is exactly one of the things I like about it. Slick easy to use GUI configuration tools, and the configuration is stored in /etc/sysconfig in a brain dead simple FOO="bar" format. How you can sit on a Fedora devel list and tell us GUIs on unix can't work, I don't know. It can work and has worked for over 5 years now. -------------- 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 pemboa at gmail.com Tue Jan 10 00:50:50 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 9 Jan 2006 18:50:50 -0600 Subject: edit root alias when installing the OS In-Reply-To: <43C2A6A7.6060204@cornell.edu> References: <1136149140.3230.5.camel@rivendell.home.local> <6280325c0601042058h17e867f9lb9059d52a75a42a8@mail.gmail.com> <20060105115906.99798940.Tommy.Reynolds@MegaCoder.com> <16de708d0601051148o827dcaase93bb815921bdc03@mail.gmail.com> <1136490840.28143.3.camel@localhost> <43BE9A8C.6000703@cornell.edu> <43BEF5CD.9020609@redhat.com> <43C276EB.2000906@cornell.edu> <43C278F0.4040908@redhat.com> <43C2A6A7.6060204@cornell.edu> Message-ID: <16de708d0601091650v71ac05e3m962741a1bd5844d@mail.gmail.com> On 1/9/06, Paul A Houle wrote: > > Rahul Sundaram wrote: > > [snipp > Perhaps things have gotten better in rawhide, but the "firewall > configuration" gimmick in RHEL is a classic example of "uselessware". > Pretty much every system I run needs to have a few ports punched in the > firewall that aren't in the list -- the firewall configuration gimmick > never remembers the ports that I've already opened, so I have to keep a > list of the ports that I've opened somewhere (or maybe look at the conf > file I'm not supposed to change) and enter them all in by hand. It's an > example of "for the want of a nail... the kingdom was lost" that often > kills GUI apps. If you are talking about system-config-securitylevel, that is just now true. The basic issue is that a GUI firewall editor has to support 100% of > the functionality I need or coexist with my ability to edit conf files > by hand, or it's 100% useless. Useless to you. A God sent by to most who haven't read through the Iptables HOWTO. A GUI app that does 90% of what I need > isn't enough if there is no workaround to get the other 10%. >> > >> To make GUIs work, Unix would have to give up on > >> human-comprehensible configuration files. (Yes, that means XML.) > > > > Many of them have indeed adopted XML but this is not the one true path > > by any means. > > > > I'm not against XML, I'm just saying that XML files don't count as > human-comprehensible and editable. Something that's basically a > database is another option, but again, other than (arguably) > relational databases, those aren't human-comprehensible and editable... > > You may not really be able to have it the GUI way and the "Unix way" > -- that doesn't mean that everyone has to stick to the Unix way. My > complaint about GUI gadgets (particularly the one in RHEL/Fedora) is > that they "almost work" and never "really work" because of a mismatch > between the data structures and the UI model. One way to get a correct > application is to make the data structures fit the UI model. There are > problems with that, but it's possible to make tools that really work > that way. You seem to be very unluck with GUIs. When ever I use a system-config-* is because it does the job easier and faster than using vi. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From canfield at uindy.edu Tue Jan 10 03:18:49 2006 From: canfield at uindy.edu (D Canfield) Date: Mon, 09 Jan 2006 22:18:49 -0500 Subject: Where's the NetworkManger applet in rawhide? In-Reply-To: <1136840009.2774.19.camel@remedyz.boston.redhat.com> References: <1136840009.2774.19.camel@remedyz.boston.redhat.com> Message-ID: <43C32799.4030406@uindy.edu> Just out of curiosity... is there any particular reason this continues to be something that has to be manually added? Couldn't it be added to Add to Panel menu? John (J5) Palmieri wrote: > It is called nm-applet now. > > On Mon, 2006-01-09 at 15:45 -0500, Sadda Teh wrote: > >> Hi, is it just me or is the NetworkManager applet missing in rawhide? >> I even re-installed NetworkManager-gnome and still I can't find >> NetworkManagerInfo on my system. What am I missing here? >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> From pjones at redhat.com Mon Jan 9 18:29:44 2006 From: pjones at redhat.com (Peter Jones) Date: Mon, 09 Jan 2006 13:29:44 -0500 Subject: mkinitrd problems with recent rawhide kernels In-Reply-To: <5256d0b0601090357q4c1ee3e5i3cbe0aa8dcecaad6@mail.gmail.com> References: <5256d0b0601090357q4c1ee3e5i3cbe0aa8dcecaad6@mail.gmail.com> Message-ID: <1136831384.16127.70.camel@localhost.localdomain> On Mon, 2006-01-09 at 11:57 +0000, Peter Robinson wrote: > Hi All, > > Is anyone else seeing issues with updating to the latest 2.6.15-1.1826 > series of kernels. I find it gets stuck in the post install script and > when I run the mkinitrd script manually it just hangs indefinately > (like when doing a yum update or manual rpm install). This is on a > Dell D600 laptop. What's mkinitrd running when it hangs? What does pstree show? If you run: mkinitrd -f -v foo.img 2.6.15-1.1826 , what does it say? -- Peter From canfield at uindy.edu Tue Jan 10 04:44:26 2006 From: canfield at uindy.edu (D Canfield) Date: Mon, 09 Jan 2006 23:44:26 -0500 Subject: SATA Suspend Kernel Patch Message-ID: <43C33BAA.1010502@uindy.edu> Is there any chance we're going to see the SATA Suspend kernel patch included in FC5 (BZ 169201)? I don't understand what the holdup is from it getting into Linus's tree (he's asked someone to submit it to him), but every other major distro seems to be using it successfully and it seems like one of the test releases would be a good time to try it if there's concern about it's stability. Just wondering if anyone knew the status. Thanks DC From dcbw at redhat.com Tue Jan 10 05:34:42 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 10 Jan 2006 00:34:42 -0500 Subject: Where's the NetworkManger applet in rawhide? In-Reply-To: <43C32799.4030406@uindy.edu> References: <1136840009.2774.19.camel@remedyz.boston.redhat.com> <43C32799.4030406@uindy.edu> Message-ID: <1136871283.4199.9.camel@localhost.localdomain> On Mon, 2006-01-09 at 22:18 -0500, D Canfield wrote: > Just out of curiosity... is there any particular reason this continues > to be something that has to be manually added? Couldn't it be added to > Add to Panel menu? Because it's not a panel applet; it's a Notification Area applet. If you have session-saving enabled, and you run /usr/bin/nm-applet, the applet will stick around. If you don't have session saving enabled, you can add it to your "Startup Programs" tab in gnome-session-properties (System->Preferences->More Preferences->Sessions) and it will show up. We don't have a good story in Gnome for adding stuff to the session automatically. It's usually a hardcoded file of stuff. ISTR there's a hack where a package can drop a .desktop file in a directory and get something added to the session next time the box starts up, but that doesn't solve the problem completely. Dan From roozbeh at farsiweb.info Tue Jan 10 09:27:02 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 10 Jan 2006 12:57:02 +0330 Subject: filelists.xml.gz: [Errno -1] Metadata file does not match checksum In-Reply-To: References: Message-ID: <1136885222.3189.5.camel@tameshk.farsiweb.info> On Mon, 2006-01-09 at 22:27 +0200, Oleg Goldshmidt wrote: > Today I am getting the following error when running "yum update" on > FC4 x86_64: > > filelists.xml.gz 100% |=========================| 3.0 MB 00:23 > http://mirror.linux.duke.edu/pub/fedora/linux/core/updates/4/x86_64/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum > Trying other mirror. > > - this is for *all* mirrors yum tries. Any ideas? Is the file > corrupted and propagated to all the mirrors? Is it a screwed-up > configuration on my end (I have not tinkered with it, actually)? > > Googling for the error message did not yield anything. What can I check? Sometimes this is because of a problematic (transparent?) proxy server. If it persists, it may be that, for which you can try setting "http_caching" in /etc/yum.conf. roozbeh From buildsys at redhat.com Tue Jan 10 09:29:05 2006 From: buildsys at redhat.com (Build System) Date: Tue, 10 Jan 2006 04:29:05 -0500 Subject: rawhide report: 20060110 changes Message-ID: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> New package beagle The Beagle Search Infrastructure New package evolution-sharp Evolution Data Server Mono Bindings New package f-spot Photo management application New package gecko-sharp2 Gecko bindings for Mono New package gmime Library for creating and parsing MIME messages New package gnome-mount Mount replacement which uses HAL to do the mounting New package gsf-sharp Mono bindings for libgsf New package gtk-sharp GTK+ and GNOME bindings for Mono New package gtk-sharp2 GTK+ and GNOME bindings for Mono New package lcms Color Management System New package libevent Abstract asynchronous event notification library New package libgdiplus libgdiplus: An Open Source implementation of the GDI+ API New package libgssapi Generic Security Services Application Programming Interface Library New package nfs-utils-lib Network File System Support Library New package pirut Package Installation, Removal and Update Tools New package sqlite2 Embeddable SQL engine in a C library New package tomboy Tomboy is a desktop note-taking application for Linux and Unix. Removed package system-config-packages Updated Packages: OpenIPMI-1.4.14-16 ------------------ * Mon Jan 09 2006 Phil Knirsch 1.4.14-16 - Included FRU fix for displaying FRUs with ipmitool - Included patch for new option to specify a BMC password for IPMI 2.0 sessions anaconda-10.91.0-1 ------------------ * Mon Jan 09 2006 Jeremy Katz - 10.91.0-1 - tweaked selection stuff a little to be the same code as pirut - tweak exception window to have an image and be better sized (dcantrell) - write out RAID device name (clumens) - scroll group list properly (dcantrell) - fix ppc rescue image (jkeating) - dmraid detection fix (pjones) authconfig-5.1.2-1 ------------------ * Mon Jan 09 2006 Tomas Mraz - 5.1.2-1 - fixed regression when saving nsswitch.conf avahi-0.6.3-1 ------------- * Mon Jan 09 2006 Jason Vas Dias - 0.6.3-1 - Upgrade to upstream version 0.6.3 - fix bug 177148: initscript start should not fail if avahi-daemon running dbus-0.60-3 ----------- * Mon Jan 09 2006 Alexander Larsson 0.60-3 - Don't exclude non-mono arches * Mon Jan 09 2006 Alexander Larsson - 0.60-2 - Add dbus-sharp sub-package e2fsprogs-1.38-5 ---------------- * Mon Jan 09 2006 Peter Jones 1.38-5 - fix some more minor logic errors in dm probing firstboot-1.3.57-1 ------------------ * Mon Jan 09 2006 Chris Lumens 1.3.57-1 - Use scdMainWindow instead of mainWindow to fix random python import tracebacks. * Mon Jan 09 2006 Chris Lumens 1.3.56-2 - Remove dependancy on system-config-packages. * Mon Jan 09 2006 Chris Lumens 1.3.56-1 - Increase timeout on waiting for X to start (#176782). - Update translations. gdm-1:2.13.0.4-2 ---------------- * Mon Jan 09 2006 Ray Strode - 1:2.13.0.4-2 - use xinit Xsession again. * Mon Jan 09 2006 Ray Strode - 1:2.13.0.4-1 - update to 2.13.0.4 glibc-2.3.90-30 --------------- * Mon Jan 09 2006 Jakub Jelinek 2.3.90-30 - update from CVS - initializer fixes for -std=c{8,9}9 on 32-bit arches - avoid writable .rodata (#177121) gnome-screensaver-0.0.23-4 -------------------------- * Mon Jan 09 2006 Ray Strode - 0.0.23-4 - don't include .desktop part of theme name in gconf schema gnome-vfs2-2.13.3-3 ------------------- * Mon Jan 09 2006 John (J5) Palmieri 2.13.3-3 - Add patch so --hal-udi is sent in when mounting and unmounting * Mon Jan 09 2006 John (J5) Palmieri 2.13.3-2 - Add dependency on gnome-mount - Add configure options for gnome-mount hal-0.5.5.1.cvs20060109-2 ------------------------- * Mon Jan 09 2006 John (J5) Palmieri - 0.5.5.1.cvs20060109-2 - Add patch to escape mount options * Mon Jan 09 2006 John (J5) Palmieri - 0.5.5.1.cvs20060109-1 - Update to a new CVS snapshot * Thu Jan 05 2006 John (J5) Palmieri - 0.5.5.1.cvs20060105-2 - readd the hotplug script java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_61rh ------------------------------------------ * Mon Jan 09 2006 Archit Shah - 0:1.4.2.0-40jpp_61rh - Import java-gcj-compat 1.0.50. jonas-0:4.3.3-1jpp_20fc ----------------------- * Mon Jan 09 2006 Jesse Keating - 4.3.3-1jpp_20fc - Exclude s390 from build * Thu Dec 22 2005 Gary Benson - 4.3.3-1jpp_19fc - Rebuild again for another gcc/gcj bug * Mon Dec 19 2005 Gary Benson - 4.3.3-1jpp_18fc - Rebuild. kernel-2.6.15-1.1826.2.9_FC5 ---------------------------- * Mon Jan 09 2006 Dave Jones - Remove vm debug patch that triggers too easily right now. (Needs fixing properly post test2). - kill blk_attempt_merge() which was horribly broken. - dm: avoid ovvrun while syncing. * Mon Jan 09 2006 David Woodhouse - Fix some usblp problems, add ieee1284_id to sysfs - update bcm43xx driver to version tested in -HEAD kernel-xen-2.6.15-1.27_FC5 -------------------------- * Mon Jan 09 2006 Stephen Tweedie - Rebase xen to hypervisor from 20060106 - Rebase xen kernel code to linux-2.6-merge.hg cset 16985 - Disable power management bits that don't work in Xen - Remove include/asm-xen from rpm * Mon Jan 09 2006 Dave Jones - Remove vm debug patch that triggers too easily right now. (Needs fixing properly post test2). - kill blk_attempt_merge() which was horribly broken. - dm: avoid ovvrun while syncing. * Mon Jan 09 2006 David Woodhouse - Fix some usblp problems, add ieee1284_id to sysfs - update bcm43xx driver to version tested in -HEAD libdaemon-0.10-2 ---------------- * Fri Jan 06 2006 Jason Vas Dias - 0.10-2 - rebuild for new gcc / glibc ltrace-0.3.36-4 --------------- * Mon Jan 09 2006 Jakub Jelinek 0.3.36-4 - added ppc64 and s390x support (IBM) - added ia64 support (Ian Wienand) * Sat Mar 05 2005 Jakub Jelinek 0.3.36-3 - rebuilt with GCC 4 * Tue Dec 14 2004 Jakub Jelinek 0.3.36-2 - make x86_64 ltrace trace both 32-bit and 64-bit binaries (#141955, IT#55600) - fix tracing across execve - fix printf-style format handling on 64-bit arches make-1:3.80-9 ------------- * Mon Jan 09 2006 Petr Machata 3.80-9 - Applied patch from hongjiu.lu at intel.com. Somehow reduces make's enormous memory consumption. (#175376) man-pages-pl-0.24-1 ------------------- * Mon Jan 09 2006 Ivana Varekova 0.24-1 - update source - add pidof patch (created by Marcin Garski) mono-1.1.12.1-1 --------------- * Mon Jan 09 2006 Alexander Larsson - 1.1.12.1-1 - Update to 1.1.12.1 * Mon Jan 09 2006 Alexander Larsson - 1.1.10-4 - rebuild * Fri Nov 18 2005 Alexander Larsson 1.1.10-3 - Disable s390 due to some build failure nautilus-2.13.3-2 ----------------- * Mon Jan 09 2006 Alexander Larsson - 2.13.3-2 - Buildrequire libbeagle * Tue Dec 13 2005 Alexander Larsson 2.13.3-1 - Update to 2.13.3 * Fri Dec 09 2005 Jesse Keating - rebuilt nfs-utils-1.0.8.rc2-1.FC5 ------------------------- * Mon Jan 09 2006 1.0.8-1 - Updated to 1.0.8-rc2 release - Broke out libgssapi into its own rpm - Move librpcsecgss and libnfsidmap in the new nfs-utils-lib rpm - Removed libevent code; Required to be installed. notify-daemon-0.3.1-3 --------------------- * Mon Jan 09 2006 Christopher Aillon - 0.3.1-3 - Fix positioning of the notification bubble to not draw off-screen openhpi-2.2.1-4 --------------- * Mon Jan 09 2006 Peter Jones 2.2.1-4 - Don't use -Werror, it doesn't build with that on ppc64 currently. * Fri Jan 06 2006 Jesse Keating 2.2.1-3 - Fix to not use stict-aliasing. * Wed Jan 04 2006 Radek Vokal 2.2.1-2 - Rebuilt against new libnetsnmp postgresql-8.1.2-1 ------------------ * Mon Jan 09 2006 Tom Lane 8.1.2-1 - Update to PostgreSQL 8.1.2 - Repair extraneous quote in pgtcl configure script ... odd that bash didn't use to spit up on this. pykickstart-0.12-1 ------------------ * Mon Jan 09 2006 Chris Lumens 0.12-1 - Clean up output quoting. - Finish removing monitor-related stuff from xconfig. rhgb-0.16.2-18 -------------- * Sun Jan 08 2006 Ray Strode 0.16.2-18 - rebuild against modular X * Thu Dec 22 2005 Jesse Keating 0.16.2-16 - versioned BuildRequires of libxf86config-devel * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc rpm-4.4.2-12 ------------ * Mon Jan 09 2006 Alexander Larsson - 4.4.2-12 - Add mono req/provides support selinux-policy-2.1.8-2 ---------------------- * Mon Jan 09 2006 Dan Walsh 2.1.8-2 - Fixes for hal and readahead * Mon Jan 09 2006 Dan Walsh 2.1.8-1 - Update to upstream - Apply * Sat Jan 07 2006 Dan Walsh 2.1.7-4 - Add wine and fix hal problems sound-juicer-2.13.1-4 --------------------- * Mon Jan 09 2006 John (J5) Palmieir 2.13.1-4 - Add a patch that adds -Wl,--export-dynamic to the build system-config-cluster-1.0.24-1.0 -------------------------------- * Mon Jan 09 2006 Jim Parsons 1.0.24-1 - Build for fedora * Tue Dec 20 2005 Jim Parsons 1.0.23-1 - Removed unnecessary fence device field * Tue Dec 20 2005 Jim Parsons 1.0.22-1 - Version bump system-config-date-1.7.99.13-1 ------------------------------ * Mon Jan 09 2006 Chris Lumens 1.7.99.13-1 - Rename mainWindow to scdMainWindow to avoid import problems in firstboot. system-config-lvm-1.0.10-1.0 ---------------------------- * Thu Jan 05 2006 Stanko Kupcevic 1.0.10-1.0 - Fix for bz176967 traceroute-2:1.0.4-1 -------------------- * Mon Jan 09 2006 Radek Vokal 1.0.4-1 - upgrade to 1.0.4 - proper fix for bug #173762 xorg-x11-fonts-1.0.0-2 ---------------------- * Tue Jan 10 2006 Bill Nottingham 1.0.0-2 - fix obsoletes (#177377) xorg-x11-xdm-1:1.0.1-1 ---------------------- * Mon Jan 09 2006 Mike A. Harris 1:1.0.1-1 - Updated xdm to version 1.0.1 from X11R7. - Added --with-xdmscriptdir option to ./configure to put scripts in /etc - Updated xdm-1.0.1-redhat-xdm-config-fix.patch to work with xdm 1.0.1 ypserv-2.13-10 -------------- * Mon Jan 09 2006 Chris Feist - 2.13-10 - Fix crash with ypxfr caused by failing to zero out data (bz #161217) * Wed Jan 04 2006 Jesse Keating - 2.13-6.2 - rebuilt for new gcc * Thu Oct 14 2004 Miloslav Trmac - 2.13-5 - Fix crash with -p (#134910, #129676) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.7.i686 requires /lib/modules/2.6.14-1.1805_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1805_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5smp jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.7.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) From fedora at camperquake.de Tue Jan 10 09:33:01 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 10 Jan 2006 10:33:01 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> Message-ID: <20060110093301.GA19191@ryoko.camperquake.de> On Tue, Jan 10, 2006 at 04:29:05AM -0500, Build System wrote: > New package beagle > The Beagle Search Infrastructure What the hell? From fedora at adslpipe.co.uk Tue Jan 10 09:35:42 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Tue, 10 Jan 2006 09:35:42 +0000 Subject: rawhide report: 20060110 changes In-Reply-To: <20060110093301.GA19191@ryoko.camperquake.de> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <20060110093301.GA19191@ryoko.camperquake.de> Message-ID: <43C37FEE.1020707@adslpipe.co.uk> Ralf Ertzinger wrote: > On Tue, Jan 10, 2006 at 04:29:05AM -0500, Build System wrote: >> New package beagle >> The Beagle Search Infrastructure > > What the hell? Read it and weep^H^H^H^Hgrin. From roozbeh at farsiweb.info Tue Jan 10 09:48:13 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 10 Jan 2006 13:18:13 +0330 Subject: rawhide report: 20060110 changes In-Reply-To: <20060110093301.GA19191@ryoko.camperquake.de> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <20060110093301.GA19191@ryoko.camperquake.de> Message-ID: <1136886494.3189.7.camel@tameshk.farsiweb.info> On Tue, 2006-01-10 at 10:33 +0100, Ralf Ertzinger wrote: > On Tue, Jan 10, 2006 at 04:29:05AM -0500, Build System wrote: > > New package beagle > > The Beagle Search Infrastructure > > What the hell? http://www.0xdeadbeef.com/?p=159 roozbeh From bart.vanbrabant at zoeloelip.be Tue Jan 10 09:48:32 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Tue, 10 Jan 2006 10:48:32 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> Message-ID: <43C382F0.9090500@zoeloelip.be> > > New package gnome-mount > Mount replacement which uses HAL to do the mounting > > When I try to run gnome-mount-properties I get these errors: gnome-mount:6204): libglade-WARNING **: could not find glade file '../gnome-mount-properties.glade' (gnome-mount:6204): libglade-CRITICAL **: glade_xml_get_widget: assertion `self != NULL' failed (gnome-mount:6204): GLib-GObject-WARNING **: invalid (NULL) pointer instance (gnome-mount:6204): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (gnome-mount:6204): Gtk-CRITICAL **: gtk_widget_show_all: assertion `GTK_IS_WIDGET (widget)' failed Seems like a bug to me. gr, Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From dennis at ausil.us Tue Jan 10 09:57:03 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 10 Jan 2006 03:57:03 -0600 Subject: rawhide report: 20060110 changes In-Reply-To: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> Message-ID: <200601100357.21617.dennis@ausil.us> Once upon a time Tuesday 10 January 2006 3:29 am, Build System wrote: > New package sqlite2 > ????????Embeddable SQL engine in a C library Was the extras maintainer notifies first? -- Dennis Gilmore, RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alexl at redhat.com Tue Jan 10 10:07:32 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 10 Jan 2006 11:07:32 +0100 Subject: bittorrent in core? what frontend? In-Reply-To: <20051220202121.GA11608@devserv.devel.redhat.com> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <20051220202121.GA11608@devserv.devel.redhat.com> Message-ID: <1136887652.8026.40.camel@greebo> On Tue, 2005-12-20 at 15:21 -0500, Alan Cox wrote: > On Mon, Dec 19, 2005 at 09:00:47AM +0100, Alexander Larsson wrote: > > I think the standard ui client looks fine for "just clicked on > > a .torrent file" actually. I'm not sure gnome-bt is better for this. > > Does the standard UI include accessibility hooks ? It uses Gtk+, and thus would have the standard atk support, but I don't know if it does anything special about a11y. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an impetuous soccer-playing cop with a secret. She's a tortured gold-digging wrestler on the trail of a serial killer. They fight crime! From bart.vanbrabant at zoeloelip.be Tue Jan 10 10:15:20 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Tue, 10 Jan 2006 11:15:20 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> Message-ID: <43C38938.5080901@zoeloelip.be> Build System wrote: > New package beagle > The Beagle Search Infrastructure > When I start beagle this doesn't work. I started beagled with --fg and I get his error: Error: Unhandled exception thrown. Exiting immediately. Error: System.TypeInitializationException: An exception was thrown by the type initializer for Evolution.SourceList ---> System.DllNotFoundException: libedataserver-1.2.so.4 in (wrapper managed-to-native) Evolution.Source:e_source_get_type () in [0x00000] (at /usr/src/redhat/BUILD/evolution-sharp-0.10.2/evolution/generated/Source.cs:296) Evolution.Source:get_GType () in [0x00011] (at /usr/src/redhat/BUILD/evolution-sharp-0.10.2/evolution/generated/ObjectManager.cs:16) GtkSharp.EvolutionSharp.ObjectManager:Initialize () in [0x00000] (at /usr/src/redhat/BUILD/evolution-sharp-0.10.2/evolution/generated/SourceList.cs:334) Evolution.SourceList:.cctor ()--- End of inner exception stack trace --- in (unmanaged) 0x80afb17 in <0x00064> Beagle.Daemon.EvolutionDataServerQueryable.SourcesHandler:.ctor (string,System.Type,Beagle.Daemon.EvolutionDataServerQueryable.EvolutionDataServerQueryable,string) in <0x000be> Beagle.Daemon.EvolutionDataServerQueryable.EvolutionDataServerQueryable:Start () in <0x00016> Beagle.Daemon.Queryable:Start () in <0x000bb> Beagle.Daemon.QueryDriver:Start () in <0x00159> Beagle.Daemon.BeagleDaemon:StartupProcess () in <0x00047> (wrapper delegate-invoke) System.MulticastDelegate:invoke_bool () in <0x0002a> IdleProxy:Handler () in <0x00036> (wrapper native-to-managed) IdleProxy:Handler () in (unmanaged) 0xa270bd in <0x00004> (wrapper managed-to-native) Gtk.Application:gtk_main () in <0x00007> Gtk.Application:Run () in <0x004f5> Beagle.Daemon.BeagleDaemon:DoMain (string[]) in <0x00014> Beagle.Daemon.BeagleDaemon:Main (string[]) Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object in [0x00014] (at /usr/src/build/677105-i386/BUILD/mono-1.1.12.1/mcs/class/corlib/System.IO/StreamWriter.cs:264) System.IO.StreamWriter:LowLevelWrite (System.String s) in [0x0001e] (at /usr/src/build/677105-i386/BUILD/mono-1.1.12.1/mcs/class/corlib/System.IO/StreamWriter.cs:313) System.IO.StreamWriter:Write (System.String value) in [0x00002] (at /usr/src/build/677105-i386/BUILD/mono-1.1.12.1/mcs/class/corlib/System.IO/UnexceptionalStreamWriter.cs:124) System.IO.UnexceptionalStreamWriter:Write (System.String value) in [0x0000d] (at /usr/src/build/677105-i386/BUILD/mono-1.1.12.1/mcs/class/corlib/System.IO/TextWriter.cs:150) System.IO.TextWriter:Write (System.Object value) in [0x0000f] (at /usr/src/build/677105-i386/BUILD/mono-1.1.12.1/mcs/class/corlib/System.IO/TextWriter.cs:423) System.IO.SynchronizedWriter:Write (System.Object value) in <0x0009f> Beagle.Util.Log:WriteLine (LogLevel level, System.String format, System.Object[] args, System.Exception ex) in <0x00011> Beagle.Util.Log:Warn (System.String message, System.Object[] args) in <0x0000d> Beagle.Util.Logger:Warn (System.String message, System.Object[] args) in <0x000a4> Beagle.Util.ExceptionHandlingThread:ThreadStarted () in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void () Should I put it in bugzilla? gr, Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From alexl at redhat.com Tue Jan 10 10:24:35 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 10 Jan 2006 11:24:35 +0100 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <200601100357.21617.dennis@ausil.us> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> Message-ID: <1136888676.8026.48.camel@greebo> On Tue, 2006-01-10 at 03:57 -0600, Dennis Gilmore wrote: > Once upon a time Tuesday 10 January 2006 3:29 am, Build System wrote: > > New package sqlite2 > > Embeddable SQL engine in a C library > > Was the extras maintainer notifies first? Unfortunately no. The same is true for gmime and lcms. I'm very sorry about this, but for obvious reasons we couldn't talk about this openly until all the decision were made, and then things turned into a horrible rush as I had to get this stuff into the tree before test2 got frozen. So, as of today the sqlite2, gmime and lcms packages that were in Fedora Extras has been moved into Core, because they were dependencies for beagle and f-spot. This was badly handled from my side, but the circumstances were unusual. How do we progress from here though. Who are the current maintainers of these extras packages? Is there an easy way to look that up? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an underprivileged small-town master criminal on the run. She's a sarcastic green-skinned schoolgirl operating on the wrong side of the law. They fight crime! From hughsient at gmail.com Tue Jan 10 10:29:46 2006 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 10 Jan 2006 10:29:46 +0000 Subject: rawhide report: 20060110 changes In-Reply-To: <43C38938.5080901@zoeloelip.be> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C38938.5080901@zoeloelip.be> Message-ID: <1136888986.3572.3.camel@localhost> On Tue, 2006-01-10 at 11:15 +0100, Bart Vanbrabant wrote: > Build System wrote: > > New package beagle > > The Beagle Search Infrastructure > > > When I start beagle this doesn't work. I started beagled with --fg and I > get his error: Same with f-spot (goto edit, preferences): Starting new FSpot server Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Cms.Profile ---> System.DllNotFoundException: liblcms.so.1 in (wrapper managed-to-native) Cms.Profile:cmsCreate_sRGBProfile () in <0x0000b> Cms.Profile:.cctor ()--- End of inner exception stack trace --- in <0x00000> in <0x00059> FSpot.ProfileList:.ctor () in <0x00075> FSpot.PreferenceDialog:.ctor () in <0x0001f> FSpot.PreferenceDialog:Show () in <0x00007> MainWindow:HandlePreferences (System.Object sender, System.EventArgs args) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs) in <0x00093> GLib.Signal:voidObjectCallback (IntPtr handle, IntPtr gch) in (wrapper native-to-managed) GLib.Signal:voidObjectCallback (intptr,intptr) in <0x00000> in (wrapper managed-to-native) Gtk.Application:gtk_main () in <0x00007> Gtk.Application:Run () in <0x00007> Gnome.Program:Run () in <0x003ba> Driver:Main (System.String[] args) Installing lcms fixes the issue. Looks like the rpm specfile needs an extra Depend. Want a bugzilla entry? Richard. From alexl at redhat.com Tue Jan 10 10:31:08 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 10 Jan 2006 11:31:08 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <43C38938.5080901@zoeloelip.be> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C38938.5080901@zoeloelip.be> Message-ID: <1136889068.8026.52.camel@greebo> On Tue, 2006-01-10 at 11:15 +0100, Bart Vanbrabant wrote: > > When I start beagle this doesn't work. I started beagled with --fg and > I get his error: I think this is an evolution-sharp vs evolution 2.6 thing. You can start beagled with --deny-backend EvolutionDataServer. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an immortal native American shaman haunted by memories of 'Nam. She's an elegant winged barmaid from Mars. They fight crime! From dennis at ausil.us Tue Jan 10 10:29:24 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 10 Jan 2006 04:29:24 -0600 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <1136888676.8026.48.camel@greebo> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> Message-ID: <200601100429.38017.dennis@ausil.us> Once upon a time Tuesday 10 January 2006 4:24 am, Alexander Larsson wrote: > On Tue, 2006-01-10 at 03:57 -0600, Dennis Gilmore wrote: > > Once upon a time Tuesday 10 January 2006 3:29 am, Build System wrote: > > > New package sqlite2 > > > Embeddable SQL engine in a C library > > > > Was the extras maintainer notifies first? > > Unfortunately no. The same is true for gmime and lcms. I'm very sorry > about this, but for obvious reasons we couldn't talk about this openly > until all the decision were made, and then things turned into a horrible > rush as I had to get this stuff into the tree before test2 got frozen. :) but understandable > So, as of today the sqlite2, gmime and lcms packages that were in Fedora > Extras has been moved into Core, because they were dependencies for > beagle and f-spot. > > This was badly handled from my side, but the circumstances were unusual. > How do we progress from here though. Who are the current maintainers of > these extras packages? Is there an easy way to look that up? owners.list in extras cvs list every package owner what is needed is a proper way to notify package maintainers. or better yet a way that extras maintainers can still maintain a package in core. -- Dennis Gilmore, RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Jan 10 10:32:24 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 10 Jan 2006 11:32:24 +0100 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <1136888676.8026.48.camel@greebo> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> Message-ID: <1136889144.8472.44.camel@thl.ct.heise.de> Am Dienstag, den 10.01.2006, 11:24 +0100 schrieb Alexander Larsson: > On Tue, 2006-01-10 at 03:57 -0600, Dennis Gilmore wrote: > > Once upon a time Tuesday 10 January 2006 3:29 am, Build System wrote: > > > New package sqlite2 > > > Embeddable SQL engine in a C library > > Was the extras maintainer notifies first? >[...] > How do we progress from here though. Who are the current maintainers of > these extras packages? Remove request for devel-Branch and the packages in the repo here: http://www.fedoraproject.org/wiki/Extras/CVSSyncNeeded > Is there an easy way to look that up? http://cvs.fedora.redhat.com/viewcvs/owners/owners.list?root=extras&view=markup HTH CU thl From bart.vanbrabant at zoeloelip.be Tue Jan 10 10:37:58 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Tue, 10 Jan 2006 11:37:58 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <1136889068.8026.52.camel@greebo> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C38938.5080901@zoeloelip.be> <1136889068.8026.52.camel@greebo> Message-ID: <43C38E86.2000005@zoeloelip.be> Alexander Larsson wrote: > On Tue, 2006-01-10 at 11:15 +0100, Bart Vanbrabant wrote: > >> When I start beagle this doesn't work. I started beagled with --fg and >> I get his error: >> > > I think this is an evolution-sharp vs evolution 2.6 thing. > > You can start beagled with --deny-backend EvolutionDataServer. > Works now. Any chance that holmes will be included too? I don't know if it had a public release yet but it's in gnome cvs and is a lot better then best. gr, Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From roozbeh at farsiweb.info Tue Jan 10 10:49:13 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 10 Jan 2006 14:19:13 +0330 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <1136888676.8026.48.camel@greebo> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> Message-ID: <1136890153.3189.19.camel@tameshk.farsiweb.info> On Tue, 2006-01-10 at 11:24 +0100, Alexander Larsson wrote: > This was badly handled from my side, but the circumstances were unusual. > How do we progress from here though. Who are the current maintainers of > these extras packages? Is there an easy way to look that up? Sure: http://cvs.fedora.redhat.com/viewcvs/owners/owners.list?root=extras&view=markup gmime: Thorsten Leemhuis lcms: Phillip Compton , but it seems that the latest releases has been done by Michael Schwendt sqlite2: Ignacio Vazquez-Abrams Also, since the extras packages require the spec name to be the same as the SRPM, you can create quick URLs. Bookmark this in Mozilla or Firefox: http://cvs.fedora.redhat.com/viewcvs/devel/%s/%s.spec?root=extras&view=markup And create a keyword for the bug, like "extras". Typing "extras sqlite2" in the URL bar will then bring you the latest spec file. (Sorry, couldn't resist it...) roozbeh From gawain.lynch at bigpond.com Tue Jan 10 12:25:27 2006 From: gawain.lynch at bigpond.com (Gawain Lynch) Date: Wed, 11 Jan 2006 01:25:27 +1300 Subject: rawhide report: 20060110 changes In-Reply-To: <20060110093301.GA19191@ryoko.camperquake.de> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <20060110093301.GA19191@ryoko.camperquake.de> Message-ID: <1136895927.6872.23.camel@legolas.felicity.net.au> On Tue, 2006-01-10 at 10:33 +0100, Ralf Ertzinger wrote: > On Tue, Jan 10, 2006 at 04:29:05AM -0500, Build System wrote: > > New package beagle > > The Beagle Search Infrastructure > > What the hell? > We are both drunk... This is *not* true, surely...??? From gawain.lynch at bigpond.com Tue Jan 10 12:30:07 2006 From: gawain.lynch at bigpond.com (Gawain Lynch) Date: Wed, 11 Jan 2006 01:30:07 +1300 Subject: rawhide report: 20060110 changes In-Reply-To: <20060110093301.GA19191@ryoko.camperquake.de> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <20060110093301.GA19191@ryoko.camperquake.de> Message-ID: <1136896207.6872.28.camel@legolas.felicity.net.au> On Tue, 2006-01-10 at 10:33 +0100, Ralf Ertzinger wrote: > On Tue, Jan 10, 2006 at 04:29:05AM -0500, Build System wrote: > > New package beagle > > The Beagle Search Infrastructure > > What the hell? > No but seriously, could someone at Red Hat please comment on this, I thought Mono was taboo due to patent issues... I just never thought I would see the day that I would see the lines of mono-1.1.12.1-1.src.rpm on an RH server... From gilboad at gmail.com Tue Jan 10 12:33:02 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 10 Jan 2006 14:33:02 +0200 Subject: rawhide report: 20060110 changes In-Reply-To: <1136896207.6872.28.camel@legolas.felicity.net.au> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <20060110093301.GA19191@ryoko.camperquake.de> <1136896207.6872.28.camel@legolas.felicity.net.au> Message-ID: <1136896382.9875.15.camel@gilboa-work-dev> On Wed, 2006-01-11 at 01:30 +1300, Gawain Lynch wrote: > On Tue, 2006-01-10 at 10:33 +0100, Ralf Ertzinger wrote: > > On Tue, Jan 10, 2006 at 04:29:05AM -0500, Build System wrote: > > > New package beagle > > > The Beagle Search Infrastructure > > > > What the hell? > > > No but seriously, could someone at Red Hat please comment on this, I > thought Mono was taboo due to patent issues... > > I just never thought I would see the day that I would see the lines of > mono-1.1.12.1-1.src.rpm on an RH server... > http://www.osnews.com/story.php?news_id=13242 http://www.0xdeadbeef.com/?p=159 Yep. Hell froze over. Gilboa From gawain.lynch at bigpond.com Tue Jan 10 12:42:04 2006 From: gawain.lynch at bigpond.com (Gawain Lynch) Date: Wed, 11 Jan 2006 01:42:04 +1300 Subject: rawhide report: 20060110 changes In-Reply-To: <1136896382.9875.15.camel@gilboa-work-dev> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <20060110093301.GA19191@ryoko.camperquake.de> <1136896207.6872.28.camel@legolas.felicity.net.au> <1136896382.9875.15.camel@gilboa-work-dev> Message-ID: <1136896924.6872.34.camel@legolas.felicity.net.au> On Tue, 2006-01-10 at 14:33 +0200, Gilboa Davara wrote: > On Wed, 2006-01-11 at 01:30 +1300, Gawain Lynch wrote: > > On Tue, 2006-01-10 at 10:33 +0100, Ralf Ertzinger wrote: > > > On Tue, Jan 10, 2006 at 04:29:05AM -0500, Build System wrote: > > > > New package beagle > > > > The Beagle Search Infrastructure > > > > > > What the hell? > > > > > No but seriously, could someone at Red Hat please comment on this, I > > thought Mono was taboo due to patent issues... > > > > I just never thought I would see the day that I would see the lines of > > mono-1.1.12.1-1.src.rpm on an RH server... > > > > http://www.osnews.com/story.php?news_id=13242 > http://www.0xdeadbeef.com/?p=159 > > Yep. > Hell froze over. > > Gilboa > It certainly did, but now I know where that lost message (with the mp3) from Lucifer is... :-) From mailinglists at erwinrol.com Tue Jan 10 13:18:26 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Tue, 10 Jan 2006 14:18:26 +0100 Subject: boot hang with 2.6.15 In-Reply-To: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> Message-ID: <1136899106.3185.5.camel@xpc.home.erwinrol.com> On Tue, 2006-01-10 at 04:29 -0500, Build System wrote: > kernel-2.6.15-1.1826.2.9_FC5 > ---------------------------- > * Mon Jan 09 2006 Dave Jones > - Remove vm debug patch that triggers too easily right now. > (Needs fixing properly post test2). > - kill blk_attempt_merge() which was horribly broken. > - dm: avoid ovvrun while syncing. > > * Mon Jan 09 2006 David Woodhouse > - Fix some usblp problems, add ieee1284_id to sysfs > - update bcm43xx driver to version tested in -HEAD After my vacation i updated my rawhide machine and it doesn't want to boot the new kernel. The boot hangs after the line; io scheduler cfg registered Only a hard reset helps at that point. The last working kernel I have is 2.6.14-1.1773_FC5. The two 2.6.15 (vmlinuz-2.6.15-1.1826.2.5_FC5 and vmlinuz-2.6.15-1.1826.2.9_FC5) kernels I have, have the same problem. this is on a x86_64 system. - Erwin From igorm5 at vip.hr Tue Jan 10 13:42:39 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Tue, 10 Jan 2006 14:42:39 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> Message-ID: <43C3B9CF.6060001@vip.hr> Build System wrote: > New package beagle > The Beagle Search Infrastructure > New package f-spot > Photo management application > New package gnome-mount > Mount replacement which uses HAL to do the mounting > gnome-screensaver-0.0.23-4 ... [root at munja ~]# yum update -y ; yum install beagle f-spot gnome-mount lcms tomboy gnome-screensaver-0.0.23-4 Setting up Update Process Setting up repositories extras : ################################################## 6/6 Reading repository metadata in from local files No Packages marked for Update/Obsoletion Setting up Install Process Setting up repositories extras : ################################################## 6/6 Reading repository metadata in from local files Parsing package install arguments No Match for argument: beagle No Match for argument: f-spot No Match for argument: gnome-mount No Match for argument: tomboy No Match for argument: gnome-screensaver-0.0.23-4 Nothing to do [root at munja ~]# cat /etc/redhat-release Fedora Core release 4 (Rawhide) -- Igor Jagec From jkeating at j2solutions.net Tue Jan 10 14:53:44 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 10 Jan 2006 09:53:44 -0500 Subject: rawhide report: 20060110 changes In-Reply-To: <43C3B9CF.6060001@vip.hr> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C3B9CF.6060001@vip.hr> Message-ID: <1136904824.5266.6.camel@ender> On Tue, 2006-01-10 at 14:42 +0100, Igor Jagec wrote: > [root at munja ~]# yum update -y ; yum install beagle f-spot gnome-mount > lcms tomboy gnome-screensaver-0.0.23-4 > Setting up Update Process > Setting up repositories > extras : ################################################## 6/6 > Reading repository metadata in from local files > No Packages marked for Update/Obsoletion > Setting up Install Process > Setting up repositories > extras : ################################################## 6/6 You only seem to have the Extras repo enabled, and not even extras-development. The mono stuff landed in the development repo. Not extras-development, development. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) From alexl at redhat.com Tue Jan 10 15:05:41 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 10 Jan 2006 16:05:41 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <43C38E86.2000005@zoeloelip.be> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C38938.5080901@zoeloelip.be> <1136889068.8026.52.camel@greebo> <43C38E86.2000005@zoeloelip.be> Message-ID: <1136905542.8026.65.camel@greebo> On Tue, 2006-01-10 at 11:37 +0100, Bart Vanbrabant wrote: > Alexander Larsson wrote: > > On Tue, 2006-01-10 at 11:15 +0100, Bart Vanbrabant wrote: > > > >> When I start beagle this doesn't work. I started beagled with --fg and > >> I get his error: > >> > > > > I think this is an evolution-sharp vs evolution 2.6 thing. > > > > You can start beagled with --deny-backend EvolutionDataServer. > > > Works now. Any chance that holmes will be included too? I don't know if > it had a public release yet but it's in gnome cvs and is a lot better > then best. Its supposed to land inside beagle eventually I think. We'll pick it up then. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a shy arachnophobic Green Beret from a doomed world. She's a strong-willed red-headed socialite who hides her beauty behind a pair of thick-framed spectacles. They fight crime! From d.lesca at solinos.it Tue Jan 10 15:14:17 2006 From: d.lesca at solinos.it (Dario Lesca) Date: Tue, 10 Jan 2006 16:14:17 +0100 Subject: FC4+Updates: howto update the database of modules using at boot Message-ID: <1136906057.3468.148.camel@lesca.home.solinos.it> Hi, when I get some FC4 update, I run anaconda-runtime and rebuild the structure and DVD.ISO image. But the new FC4+Patch not see some SCSI controller (new mpt* modules), the new modules not are into modules.cgz. > [root at lesca makebootdisk.dir.5797]# cd modules/ > [root at lesca modules]# ls > module-info modules.cgz modules.dep modules.pcimap > modules.usbmap pci.ids pcitable > [root at lesca modules]# grep mpt * > module-info:mptbase > module-info:mptscsih > modules.dep:mptspi: mptscsih mptbase scsi_mod > modules.dep:mptscsih: mptbase scsi_mod > modules.dep:mptsas: mptscsih mptbase scsi_transport_sas scsi_mod > modules.dep:mptlan: mptbase > modules.dep:mptfc: mptscsih mptbase scsi_mod > modules.dep:mptctl: mptbase > modules.dep:mptspi: mptscsih mptbase scsi_mod > modules.dep:mptscsih: mptbase scsi_mod > modules.dep:mptsas: mptscsih mptbase scsi_transport_sas scsi_mod > modules.dep:mptfc: mptscsih mptbase scsi_mod > modules.dep:mptspi: mptscsih mptbase scsi_mod > modules.dep:mptscsih: mptbase scsi_mod > modules.dep:mptsas: mptscsih mptbase scsi_transport_sas scsi_mod > modules.dep:mptfc: mptscsih mptbase scsi_mod > modules.dep:mptlan: mptbase > [root at lesca modules]# vi module-info > [root at lesca modules]# gzip -dc modules.cgz|cpio -it|grep mpt > 2.6.14-1.1656_FC4/i586/mptbase.ko > 2.6.14-1.1656_FC4/i586/mptscsih.ko > 15999 blocks > Is possible insert into modules.cgz (and in module-info) the new mtp modules before rebuild the structure ? How To do that? Many thanks to all! FC4 is a good linux Distro! -- Dario Lesca From alexl at redhat.com Tue Jan 10 15:18:39 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 10 Jan 2006 16:18:39 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <1136888986.3572.3.camel@localhost> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C38938.5080901@zoeloelip.be> <1136888986.3572.3.camel@localhost> Message-ID: <1136906320.8026.67.camel@greebo> On Tue, 2006-01-10 at 10:29 +0000, Richard Hughes wrote: > Installing lcms fixes the issue. Looks like the rpm spcfile needs an > extra Depend. Want a bugzilla entry? No need, i'm building with this fix atm. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a war-weary alcoholic dwarf on the wrong side of the law. She's a sharp-shooting punk bounty hunter with her own daytime radio talk show. They fight crime! From david at fubar.dk Tue Jan 10 15:54:04 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 10 Jan 2006 10:54:04 -0500 Subject: rawhide report: 20060110 changes In-Reply-To: <43C382F0.9090500@zoeloelip.be> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C382F0.9090500@zoeloelip.be> Message-ID: <1136908444.5892.1.camel@daxter.boston.redhat.com> On Tue, 2006-01-10 at 10:48 +0100, Bart Vanbrabant wrote: > > > > New package gnome-mount > > Mount replacement which uses HAL to do the mounting > > > > > When I try to run gnome-mount-properties I get these errors: Yes, this is well-known; gnome-mount still needs a lot of work but at least now it does the basics as a fstab-sync replacement. Send patches to utopia-list at gnome.org (I already got a patch for this one btw). David From igorm5 at vip.hr Tue Jan 10 15:56:50 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Tue, 10 Jan 2006 16:56:50 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <1136904824.5266.6.camel@ender> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C3B9CF.6060001@vip.hr> <1136904824.5266.6.camel@ender> Message-ID: <43C3D942.9000105@vip.hr> Jesse Keating wrote: > On Tue, 2006-01-10 at 14:42 +0100, Igor Jagec wrote: >>[root at munja ~]# yum update -y ; yum install beagle f-spot gnome-mount >>lcms tomboy gnome-screensaver-0.0.23-4 >>Setting up Update Process >>Setting up repositories >>extras : ################################################## 6/6 >>Reading repository metadata in from local files >>No Packages marked for Update/Obsoletion >>Setting up Install Process >>Setting up repositories >>extras : ################################################## 6/6 > You only seem to have the Extras repo enabled, and not even > extras-development. The mono stuff landed in the development repo. Not > extras-development, development. Nope. Here's my enabled repos: [development] name=Fedora Core $releasever - Development Tree #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide enabled=1 gpgcheck=0 [extras-development] name=Fedora Extras $releasever - Development Tree #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/ mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-devel enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras gpgcheck=0 [extras] name=Fedora Extras $releasever - $basearch #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/$releasever/$basearch/ mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-$releasever enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras gpgcheck=0 [base] name=Fedora Core $releasever - $basearch - Base #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/os/ mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-$releasever enabled=1 gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora -- Igor Jagec From pbrobinson at gmail.com Tue Jan 10 15:57:02 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 10 Jan 2006 15:57:02 +0000 Subject: mkinitrd problems with recent rawhide kernels In-Reply-To: <1136831384.16127.70.camel@localhost.localdomain> References: <5256d0b0601090357q4c1ee3e5i3cbe0aa8dcecaad6@mail.gmail.com> <1136831384.16127.70.camel@localhost.localdomain> Message-ID: <5256d0b0601100757t62477437scb179435a2421ad6@mail.gmail.com> On 1/9/06, Peter Jones wrote: > On Mon, 2006-01-09 at 11:57 +0000, Peter Robinson wrote: > > Hi All, > > > > Is anyone else seeing issues with updating to the latest 2.6.15-1.1826 > > series of kernels. I find it gets stuck in the post install script and > > when I run the mkinitrd script manually it just hangs indefinately > > (like when doing a yum update or manual rpm install). This is on a > > Dell D600 laptop. > > What's mkinitrd running when it hangs? What does pstree show? > > If you run: > > mkinitrd -f -v foo.img 2.6.15-1.1826 , what does it say? Seems to have settled down with todays kernel update, so not sure what it was. Pete From pbrobinson at gmail.com Tue Jan 10 15:59:34 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 10 Jan 2006 15:59:34 +0000 Subject: More mass rebuilds for GCC In-Reply-To: <20060109195009.58f4fb31.fedora@wir-sind-cool.org> References: <1134891796.5262.19.camel@ender> <20060109123723.641198d7.fedora@wir-sind-cool.org> <5256d0b0601090338j65ebeee2v1faf2f23ac7c346f@mail.gmail.com> <20060109195009.58f4fb31.fedora@wir-sind-cool.org> Message-ID: <5256d0b0601100759m614c5178se928026f6295fc04@mail.gmail.com> > > > > As you'll notice, there will be lots more packages bumped for the rebase > > > > to gcc. Most completed today, but we'll be working through a list of > > > > failures over the next couple days. Things will still be in a bit of > > > > flux, but we're working on it. > > > > > > > > Java is still being worked on too. Getting the java stack built with > > > > gcj is a great accomplishment and I really respect our java and gcj team > > > > for putting in the work to further the free java. Please bare with us > > > > as we finalize the development changes necessary to accomplish this > > > > task. > > > > > > Does the new GCC introduce any run-time/ABI breakage which requires > > > packages in Fedora Extras Development to be rebuilt? Or does it only > > > reveal problematic source code? > > > > I think all the extras need to be rebuilt for this. I know seahorse > > for one needs it (and may need some fixes). > > AFAIK, seahorse was affected by SONAME changes in some of its > dependencies, which made a rebuild necessary. That was a change not > related to the GCC upgrade. My question is not about ordinary breakage > through upgrades of dependencies. Yes, I think that's true but I also think there is some gcc41 rebuild issues with it too (well there seems to be when I just try to rebuild the srpm. I think the binaries produced by gcc 4 and 4.1 are compatible so most things won't need to be rebuilt, but then its probably good for them to be rebuilt too. Pete From bart.vanbrabant at zoeloelip.be Tue Jan 10 16:08:06 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Tue, 10 Jan 2006 17:08:06 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <1136889068.8026.52.camel@greebo> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C38938.5080901@zoeloelip.be> <1136889068.8026.52.camel@greebo> Message-ID: <43C3DBE6.6050101@zoeloelip.be> Alexander Larsson wrote: > On Tue, 2006-01-10 at 11:15 +0100, Bart Vanbrabant wrote: > >> When I start beagle this doesn't work. I started beagled with --fg and >> I get his error: >> > > I think this is an evolution-sharp vs evolution 2.6 thing. > > You can start beagled with --deny-backend EvolutionDataServer. > > I updated the patch in gnome bugzilla but there is still an issue with the glue library: http://bugzilla.gnome.org/show_bug.cgi?id=320190 -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From adrian at lisas.de Tue Jan 10 16:09:09 2006 From: adrian at lisas.de (Adrian Reber) Date: Tue, 10 Jan 2006 17:09:09 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <43C3D942.9000105@vip.hr> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C3B9CF.6060001@vip.hr> <1136904824.5266.6.camel@ender> <43C3D942.9000105@vip.hr> Message-ID: <20060110160909.GA21891@lisas.de> On Tue, Jan 10, 2006 at 04:56:50PM +0100, Igor Jagec wrote: > > On Tue, 2006-01-10 at 14:42 +0100, Igor Jagec wrote: > >>[root at munja ~]# yum update -y ; yum install beagle f-spot gnome-mount > >>lcms tomboy gnome-screensaver-0.0.23-4 > >>Setting up Update Process > >>Setting up repositories > >>extras : ################################################## 6/6 > >>Reading repository metadata in from local files > >>No Packages marked for Update/Obsoletion > >>Setting up Install Process > >>Setting up repositories > >>extras : ################################################## 6/6 > > You only seem to have the Extras repo enabled, and not even > > extras-development. The mono stuff landed in the development repo. Not > > extras-development, development. > > Nope. Here's my enabled repos: > > [development] > name=Fedora Core $releasever - Development Tree > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ > mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide > enabled=1 > gpgcheck=0 yum probably selected a mirror from the mirror list which was not updated yet. Adrian -- Adrian Reber http://lisas.de/~adrian/ Memory fault -- brain fried From canfield at uindy.edu Tue Jan 10 16:20:13 2006 From: canfield at uindy.edu (D Canfield) Date: Tue, 10 Jan 2006 11:20:13 -0500 Subject: Where's the NetworkManger applet in rawhide? In-Reply-To: <1136871283.4199.9.camel@localhost.localdomain> References: <1136840009.2774.19.camel@remedyz.boston.redhat.com> <43C32799.4030406@uindy.edu> <1136871283.4199.9.camel@localhost.localdomain> Message-ID: <43C3DEBD.9030702@uindy.edu> Dan Williams wrote: >On Mon, 2006-01-09 at 22:18 -0500, D Canfield wrote: > > >>Just out of curiosity... is there any particular reason this continues >>to be something that has to be manually added? Couldn't it be added to >>Add to Panel menu? >> >> > >Because it's not a panel applet; it's a Notification Area applet. If >you have session-saving enabled, and you run /usr/bin/nm-applet, the >applet will stick around. If you don't have session saving enabled, you >can add it to your "Startup Programs" tab in gnome-session-properties >(System->Preferences->More Preferences->Sessions) and it will show up. > > I understand the technical difference... but what's the difference for the end-user? Why does nm-applet have to be started differently than gnome-netstatus-applet and how does a user know the difference... they both appear on the panel and they both provide similar functionality. NetworkManager provides very important functionality for users, and it needs to be more obvious how to use it. Just looking at the mailing lists for the various distributions I've tried lately, "how do I start the NetworkManager applet" has been asked probably 5-10 times on each list. And this is from people who already know that the applet exists. If we can't figure out a good way to add/remove it from the panel, should we consider adding it to the session by default? A similar "conflict" seems to exist with the two battery monitors. Though in that case, battstat-applet seems to totally overlap with gnome-power-manager. Any reason not to remove the former? From igorm5 at vip.hr Tue Jan 10 16:24:12 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Tue, 10 Jan 2006 17:24:12 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <20060110160909.GA21891@lisas.de> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C3B9CF.6060001@vip.hr> <1136904824.5266.6.camel@ender> <43C3D942.9000105@vip.hr> <20060110160909.GA21891@lisas.de> Message-ID: <43C3DFAC.5000602@vip.hr> Adrian Reber wrote: > yum probably selected a mirror from the mirror list which was not > updated yet. Does that depend on where I am from? That stuff with Yum? I'm from Croatia if that means something... Nevermind, I'm gonna update my Rawhide system tomorrow. Thanks anyway. -- Igor Jagec From sundaram at redhat.com Tue Jan 10 16:27:13 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 10 Jan 2006 21:57:13 +0530 Subject: rawhide report: 20060110 changes In-Reply-To: <43C3DFAC.5000602@vip.hr> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C3B9CF.6060001@vip.hr> <1136904824.5266.6.camel@ender> <43C3D942.9000105@vip.hr> <20060110160909.GA21891@lisas.de> <43C3DFAC.5000602@vip.hr> Message-ID: <43C3E061.80007@redhat.com> Igor Jagec wrote: >Adrian Reber wrote: > > > >>yum probably selected a mirror from the mirror list which was not >>updated yet. >> >> > >Does that depend on where I am from? That stuff with Yum? I'm from >Croatia if that means something... Nevermind, I'm gonna update my >Rawhide system tomorrow. Thanks anyway. > > > Yum chooses a repository in a random way so its not dependent on the region you are in. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From canfield at uindy.edu Tue Jan 10 16:28:32 2006 From: canfield at uindy.edu (D Canfield) Date: Tue, 10 Jan 2006 11:28:32 -0500 Subject: SATA Suspend Kernel Patch In-Reply-To: <43C33BAA.1010502@uindy.edu> References: <43C33BAA.1010502@uindy.edu> Message-ID: <43C3E0B0.6030702@uindy.edu> D Canfield wrote: > Is there any chance we're going to see the SATA Suspend kernel patch > included in FC5 (BZ 169201)? I don't understand what the holdup is > from it getting into Linus's tree (he's asked someone to submit it to > him), but every other major distro seems to be using it successfully > and it seems like one of the test releases would be a good time to try > it if there's concern about it's stability. Just wondering if anyone > knew the status. > > Thanks > DC > Following up, the thinkwiki suggests that this patch is now in the kernel 2.6.16 development. So now the patch is "blessed." Maybe it can wait for 2.6.16 to be rolled in, but my concern is now with timing. Will kernel updates be rolled in all through FC development, or will there be a stabilizing point at which the kernel needs to freeze (more than just a week or two before release, I mean)? And more generally, will FC5 be as aggressive with updates (both kernel and otherwise) as FC4, or was that a special circumstance due to the long development window for FC5? Just curious. Thanks DC From d.jacobfeuerborn at conversis.de Tue Jan 10 16:29:49 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Tue, 10 Jan 2006 17:29:49 +0100 Subject: Mono app packaging Message-ID: <43C3E0FD.2040702@conversis.de> Hi, I noticed that at least in the packages for f-spot and beagle the executable binaries are located in "/usr/lib//*.exe" and that "/usr/bin" merely contains stub scripts that call these executables. This looks quite ugly to me as it defeats the standard filesystem hierarchy so is this something temporary or is this so kind of "best practice" for mono applications? Regards, Dennis From igorm5 at vip.hr Tue Jan 10 16:32:35 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Tue, 10 Jan 2006 17:32:35 +0100 Subject: system-config-packages replacement Message-ID: <43C3E1A3.7020809@vip.hr> I saw that system-config-packages package is removed from Rawhide. What package will be replacement for it? Is it going to be Yumex, or something depends on Yum? Thanks! Cheers! -- Igor Jagec From canfield at uindy.edu Tue Jan 10 16:33:56 2006 From: canfield at uindy.edu (D Canfield) Date: Tue, 10 Jan 2006 11:33:56 -0500 Subject: Thunderbird editor Message-ID: <43C3E1F4.3090402@uindy.edu> I'm having a lot of trouble with the thunderbird 1.5 editor. Cursor movement bounces around somewhat unexpectedly and it's crashed on me several times when doing cuts and pastes (even a simple backspace did it once). I've never had a mozilla product be this unstable. Am I the only one experiencing this? If not, do we know it it's a problem with the 1.5 branch, or something that's been introduced in the FC5 environment? I'd strongly advocate rolling back to 1.0.x if nothing can be done to stabilize this. Thanks DC From sundaram at redhat.com Tue Jan 10 16:41:30 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 10 Jan 2006 22:11:30 +0530 Subject: system-config-packages replacement In-Reply-To: <43C3E1A3.7020809@vip.hr> References: <43C3E1A3.7020809@vip.hr> Message-ID: <43C3E3BA.4030200@redhat.com> Igor Jagec wrote: >I saw that system-config-packages package is removed from Rawhide. What >package will be replacement for it? Is it going to be Yumex, or >something depends on Yum? > > Pirut, which is a rewite of system-config-packages with a yum backend is the replacement for it. Jeremy Katz (pirut developer/maintainer) blogged on this before. http://www.livejournal.com/users/katzj/378558.html -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at redhat.com Tue Jan 10 16:43:44 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 10 Jan 2006 22:13:44 +0530 Subject: Fedora Directory Server in rawhide/FC5? In-Reply-To: <20051204144144.GA2312@neu.nirvana> References: <20051204144144.GA2312@neu.nirvana> Message-ID: <43C3E440.3020002@redhat.com> Axel Thimm wrote: >Hi, > >it is too late to have FDS be part of FC5, isn't it? Is anyone working >on pushing a package into rawhide anyway? > > It probably needs more work before getting into FC. Maybe FC6. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From pjones at redhat.com Tue Jan 10 16:44:09 2006 From: pjones at redhat.com (Peter Jones) Date: Tue, 10 Jan 2006 11:44:09 -0500 Subject: system-config-packages replacement In-Reply-To: <43C3E1A3.7020809@vip.hr> References: <43C3E1A3.7020809@vip.hr> Message-ID: <1136911449.18949.12.camel@localhost.localdomain> On Tue, 2006-01-10 at 17:32 +0100, Igor Jagec wrote: > I saw that system-config-packages package is removed from Rawhide. What > package will be replacement for it? Is it going to be Yumex, or > something depends on Yum? pirut, which was added last night. -- Peter From roozbeh at farsiweb.info Tue Jan 10 16:44:31 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 10 Jan 2006 20:14:31 +0330 Subject: system-config-packages replacement In-Reply-To: <43C3E1A3.7020809@vip.hr> References: <43C3E1A3.7020809@vip.hr> Message-ID: <1136911471.3189.89.camel@tameshk.farsiweb.info> On Tue, 2006-01-10 at 17:32 +0100, Igor Jagec wrote: > I saw that system-config-packages package is removed from Rawhide. What > package will be replacement for it? Is it going to be Yumex, or > something depends on Yum? The replacement is named "pirut", from what I've learned on the IRC. I don't know what exactly is the history, and if it's just a name change or what. roozbeh From hughsient at gmail.com Tue Jan 10 16:49:25 2006 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 10 Jan 2006 16:49:25 +0000 Subject: Fedora Directory Server in rawhide/FC5? In-Reply-To: <43C3E440.3020002@redhat.com> References: <20051204144144.GA2312@neu.nirvana> <43C3E440.3020002@redhat.com> Message-ID: <1136911765.22873.26.camel@localhost> On Tue, 2006-01-10 at 22:13 +0530, Rahul Sundaram wrote: > Axel Thimm wrote: > > >Hi, > > > >it is too late to have FDS be part of FC5, isn't it? Is anyone working > >on pushing a package into rawhide anyway? > > > > > It probably needs more work before getting into FC. Maybe FC6. Doesn't it still need a non-free java? Richard. From jspaleta at gmail.com Tue Jan 10 16:47:48 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 10 Jan 2006 11:47:48 -0500 Subject: Mono app packaging In-Reply-To: <43C3E0FD.2040702@conversis.de> References: <43C3E0FD.2040702@conversis.de> Message-ID: <604aa7910601100847k108fc27eg1a47e709429ad4d@mail.gmail.com> On 1/10/06, Dennis Jacobfeuerborn wrote: > Hi, > I noticed that at least in the packages for f-spot and beagle the > executable binaries are located in "/usr/lib//*.exe" and that > "/usr/bin" merely contains stub scripts that call these executables. This > looks quite ugly to me as it defeats the standard filesystem hierarchy so > is this something temporary or is this so kind of "best practice" for mono > applications? I'm not sure what the fuss is about, mozilla and firefox and openoffice all do this sort of thing already. We aren't setting in precedences with wrapper script usage here. If you have just noticed this with the mono apps, then clearly this isn't such a big deal your system has been using this sort of construction for awhile now and you have been blissfully ignorant of it. -jef From michael.favia at insitesinc.com Tue Jan 10 16:50:39 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Tue, 10 Jan 2006 10:50:39 -0600 Subject: Thunderbird editor In-Reply-To: <43C3E1F4.3090402@uindy.edu> References: <43C3E1F4.3090402@uindy.edu> Message-ID: <43C3E5DF.3070806@insitesinc.com> D Canfield wrote: > I'm having a lot of trouble with the thunderbird 1.5 editor. Cursor > movement bounces around somewhat unexpectedly and it's crashed on me > several times when doing cuts and pastes (even a simple backspace did it > once). I've never had a mozilla product be this unstable. Am I the > only one experiencing this? If not, do we know it it's a problem with > the 1.5 branch, or something that's been introduced in the FC5 > environment? wfm. > I'd strongly advocate rolling back to 1.0.x if nothing can > be done to stabilize this. i doubt you'll get many me too's. -mf From sundaram at redhat.com Tue Jan 10 16:53:55 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 10 Jan 2006 22:23:55 +0530 Subject: Thunderbird editor In-Reply-To: <43C3E1F4.3090402@uindy.edu> References: <43C3E1F4.3090402@uindy.edu> Message-ID: <43C3E6A3.7060404@redhat.com> D Canfield wrote: > I'm having a lot of trouble with the thunderbird 1.5 editor. Cursor > movement bounces around somewhat unexpectedly and it's crashed on me > several times when doing cuts and pastes (even a simple backspace did > it once). I've never had a mozilla product be this unstable. Am I > the only one experiencing this? If not, do we know it it's a problem > with the 1.5 branch, or something that's been introduced in the FC5 > environment? I'd strongly advocate rolling back to 1.0.x if nothing > can be done to stabilize this. We still have sometime before the GA release to get this stuff fixed. Bugzilla awaits you. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From michael.favia at insitesinc.com Tue Jan 10 16:53:55 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Tue, 10 Jan 2006 10:53:55 -0600 Subject: Linuxwacom driver update Message-ID: <43C3E6A3.3000101@insitesinc.com> The linuxwacom project has released a new version that adds support for the graphire 4 and a number of other new wacom tablets. Is there any chance of updating the FC package before fc5? -mf From site: It supports kernel 2.6.13/14 and a few new tablets (Graphire4, PL710, DTF720, Intuos3 6x11 and Volito2). It also reports tool ID and serial number to Xinput/Apps through valuators. No need to build mousedev.c, evdev.c, and usbmouse.c for kernel 2.6.x and modify /dev/input/mice in /etc/X11/xorg.conf anymore! From dragoran at feuerpokemon.de Tue Jan 10 16:59:52 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 10 Jan 2006 17:59:52 +0100 Subject: system-config-packages replacement In-Reply-To: <1136911471.3189.89.camel@tameshk.farsiweb.info> References: <43C3E1A3.7020809@vip.hr> <1136911471.3189.89.camel@tameshk.farsiweb.info> Message-ID: <43C3E808.4010303@feuerpokemon.de> Roozbeh Pournader wrote: >On Tue, 2006-01-10 at 17:32 +0100, Igor Jagec wrote: > > >>I saw that system-config-packages package is removed from Rawhide. What >>package will be replacement for it? Is it going to be Yumex, or >>something depends on Yum? >> >> > >The replacement is named "pirut", from what I've learned on the IRC. I >don't know what exactly is the history, and if it's just a name change >or what. > >roozbeh > > > > tested it (its in rawhide) seems that it still in early stages From canfield at uindy.edu Tue Jan 10 17:05:16 2006 From: canfield at uindy.edu (D Canfield) Date: Tue, 10 Jan 2006 12:05:16 -0500 Subject: Thunderbird editor In-Reply-To: <43C3E5DF.3070806@insitesinc.com> References: <43C3E1F4.3090402@uindy.edu> <43C3E5DF.3070806@insitesinc.com> Message-ID: <43C3E94C.4020203@uindy.edu> Michael Favia wrote: > D Canfield wrote: > >> I'm having a lot of trouble with the thunderbird 1.5 editor. Cursor >> movement bounces around somewhat unexpectedly and it's crashed on me >> several times when doing cuts and pastes (even a simple backspace did >> it once). I've never had a mozilla product be this unstable. Am I >> the only one experiencing this? If not, do we know it it's a problem >> with the 1.5 branch, or something that's been introduced in the FC5 >> environment? > > wfm. One example: Place the cursor in the middle of a line inside a paragraph of text. Press the up or down arrow and the cursor moves to beginning or end of the next line, not to the same position in the line as is expected. I don't remember all the problems off the top of my head, but that's the sort of thing I'm seeing when things work. The crashes I can't repeat on demand. Though I've noticed that it's usually when I'm replying to people and often will happen twice when working on the same reply. So maybe it's something with the quoting functionality. >> I'd strongly advocate rolling back to 1.0.x if nothing can be done to >> stabilize this. > > i doubt you'll get many me too's. > If I'm the only one seeing problems, then my point is moot. Otherwise, I hope you're wrong about the general sentiment being that a package should be kept even if it's unstable (which is why I said "if nothing can be done"... I didn't mean it should be rolled back tomorrow or anything). DC From ivazquez at ivazquez.net Tue Jan 10 17:08:38 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 10 Jan 2006 12:08:38 -0500 Subject: Linuxwacom driver update In-Reply-To: <43C3E6A3.3000101@insitesinc.com> References: <43C3E6A3.3000101@insitesinc.com> Message-ID: <1136912918.20552.4.camel@ignacio.lan> On Tue, 2006-01-10 at 10:53 -0600, Michael Favia wrote: > The linuxwacom project has released a new version that adds support for > the graphire 4 and a number of other new wacom tablets. Is there any > chance of updating the FC package before fc5? -mf http://bugzilla.redhat.com/ -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 jfrieben at freesurf.fr Tue Jan 10 16:08:36 2006 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Tue, 10 Jan 2006 17:08:36 +0100 (CET) Subject: rawhide report: 20060110 changes In-Reply-To: <43C3D942.9000105@vip.hr> References: <43C3D942.9000105@vip.hr> Message-ID: <51932.194.94.224.254.1136909316.squirrel@arlette.freesurf.fr> Sometimes mirrors need a while to get updated. No reason to worry unless this continues for a longer period of time. JF > > Nope. Here's my enabled repos: > > [development] > name=Fedora Core $releasever - Development Tree > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/> mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-rawhide > enabled=1 > gpgcheck=0 > > [extras-development] > name=Fedora Extras $releasever - Development Tree > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/$basearch/> mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-devel > enabled=1 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras > gpgcheck=0 > > [extras] > name=Fedora Extras $releasever - $basearch > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/$releasever/$basearch/> mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-extras-$releasever> enabled=1 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras > gpgcheck=0 > > [base] > name=Fedora Core $releasever - $basearch - Base > #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/os/> mirrorlist=http://fedora.redhat.com/download/mirrors/fedora-core-$releasever> enabled=1 > gpgcheck=0 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora > > -- > Igor Jagec > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From mpeters at mac.com Tue Jan 10 17:15:16 2006 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 10 Jan 2006 09:15:16 -0800 Subject: system-config-network-tui In-Reply-To: <43C13286.2080408@vip.hr> References: <43C12B6A.8090602@vip.hr> <43C12E18.1060402@redhat.com> <43C13286.2080408@vip.hr> Message-ID: <1136913316.17436.15.camel@locolhost.localdomain> On Sun, 2006-01-08 at 16:40 +0100, Igor Jagec wrote: > Rahul Sundaram wrote: > > > If you are working on wireless connections, Network Manager might be > > more appropriate http://fedoraproject.org/wiki/Tools/NetworkManager > > I don't like that tool. It breaks my wireless connection very often. I > removed it from my system immediately. I read some experiences on news > groups about breaking ADSL connection, and so on. Maybe I didn't look in the right places, my problem with it was that it seemed to insist on running a caching nameserver, which is no good for me because I need to use the nameserver provided by whichever dhcp I'm connected to at the moment for resolving some internal hostnames. So I just use Network Device Control and edit it when necessary. From michael.favia at insitesinc.com Tue Jan 10 17:26:53 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Tue, 10 Jan 2006 11:26:53 -0600 Subject: bugzilla session expires [WAS: Re: Linuxwacom driver update] In-Reply-To: <1136912918.20552.4.camel@ignacio.lan> References: <43C3E6A3.3000101@insitesinc.com> <1136912918.20552.4.camel@ignacio.lan> Message-ID: <43C3EE5D.6060501@insitesinc.com> Ignacio Vazquez-Abrams wrote: > On Tue, 2006-01-10 at 10:53 -0600, Michael Favia wrote: >> The linuxwacom project has released a new version that adds support for >> the graphire 4 and a number of other new wacom tablets. Is there any >> chance of updating the FC package before fc5? -mf > > http://bugzilla.redhat.com/ Does anyone else have to re-log into bugzilla every other page? Or is it some session cookie setting i have set in firefox (i allow cookies but only until firefox session ends)? -mf From michael.favia at insitesinc.com Tue Jan 10 17:29:47 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Tue, 10 Jan 2006 11:29:47 -0600 Subject: Thunderbird editor In-Reply-To: <43C3E94C.4020203@uindy.edu> References: <43C3E1F4.3090402@uindy.edu> <43C3E5DF.3070806@insitesinc.com> <43C3E94C.4020203@uindy.edu> Message-ID: <43C3EF0B.1020909@insitesinc.com> D Canfield wrote: > One example: Place the cursor in the middle of a line inside a paragraph > of text. Press the up or down arrow and the cursor moves to beginning > or end of the next line, not to the same position in the line as is > expected. I don't remember all the problems off the top of my head, but > that's the sort of thing I'm seeing when things work. The crashes I > can't repeat on demand. Though I've noticed that it's usually when I'm > replying to people and often will happen twice when working on the same > reply. So maybe it's something with the quoting functionality. Wow. Missed it till now but +1 on the arrow up behavior. Bugzillaing it would help resolve the issue. Any others youd like to confirm? -mf From pmatilai at laiskiainen.org Tue Jan 10 17:34:24 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 10 Jan 2006 19:34:24 +0200 Subject: system-config-packages replacement In-Reply-To: <43C3E3BA.4030200@redhat.com> References: <43C3E1A3.7020809@vip.hr> <43C3E3BA.4030200@redhat.com> Message-ID: <1136914464.30703.26.camel@weasel.turre.laiskiainen.org> On Tue, 2006-01-10 at 22:11 +0530, Rahul Sundaram wrote: > Igor Jagec wrote: > > >I saw that system-config-packages package is removed from Rawhide. What > >package will be replacement for it? Is it going to be Yumex, or > >something depends on Yum? > > > > > Pirut, which is a rewite of system-config-packages with a yum backend is > the replacement for it. Jeremy Katz (pirut developer/maintainer) blogged > on this before. > > http://www.livejournal.com/users/katzj/378558.html "Pirut"? LOL, that's "devils" in Finnish... - Panu - From icon at fedoraproject.org Tue Jan 10 17:41:09 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 10 Jan 2006 12:41:09 -0500 Subject: system-config-packages replacement In-Reply-To: <1136914464.30703.26.camel@weasel.turre.laiskiainen.org> References: <43C3E1A3.7020809@vip.hr> <43C3E3BA.4030200@redhat.com> <1136914464.30703.26.camel@weasel.turre.laiskiainen.org> Message-ID: <1136914869.11377.25.camel@rakta.wsg.mcgill.ca> On Tue, 2006-10-01 at 19:34 +0200, Panu Matilainen wrote: > > "Pirut"? > > LOL, that's "devils" in Finnish... Let's rename it to "Blue Devils" in Finnish and it'll be a nice homage to the birthplace of Yum. :) Cheers, -- Konstantin Ryabitsev McGill University WSG Wash: "You know, it's all very sweet, stealing from the rich, selling to the poor..." From canfield at uindy.edu Tue Jan 10 17:52:26 2006 From: canfield at uindy.edu (D Canfield) Date: Tue, 10 Jan 2006 12:52:26 -0500 Subject: Thunderbird editor In-Reply-To: <43C3EF0B.1020909@insitesinc.com> References: <43C3E1F4.3090402@uindy.edu> <43C3E5DF.3070806@insitesinc.com> <43C3E94C.4020203@uindy.edu> <43C3EF0B.1020909@insitesinc.com> Message-ID: <43C3F45A.20602@uindy.edu> Michael Favia wrote: > D Canfield wrote: >> One example: Place the cursor in the middle of a line inside a >> paragraph of text. Press the up or down arrow and the cursor moves >> to beginning or end of the next line, not to the same position in the >> line as is expected. I don't remember all the problems off the top >> of my head, but that's the sort of thing I'm seeing when things >> work. The crashes I can't repeat on demand. Though I've noticed >> that it's usually when I'm replying to people and often will happen >> twice when working on the same reply. So maybe it's something with >> the quoting functionality. > > Wow. Missed it till now but +1 on the arrow up behavior. Bugzillaing > it would help resolve the issue. Any others youd like to confirm? -mf > 177436 on the cursor tracking bug, and 176227 already existed on the crashing. From mharris at mharris.ca Tue Jan 10 18:29:42 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 10 Jan 2006 13:29:42 -0500 Subject: Linuxwacom driver update In-Reply-To: <43C3E6A3.3000101@insitesinc.com> References: <43C3E6A3.3000101@insitesinc.com> Message-ID: <43C3FD16.2080309@mharris.ca> Michael Favia wrote: > The linuxwacom project has released a new version that adds support for > the graphire 4 and a number of other new wacom tablets. Is there any > chance of updating the FC package before fc5? -mf > > From site: > It supports kernel 2.6.13/14 and a few new tablets (Graphire4, PL710, > DTF720, Intuos3 6x11 and Volito2). It also reports tool ID and serial > number to Xinput/Apps through valuators. No need to build mousedev.c, > evdev.c, and usbmouse.c for kernel 2.6.x and modify /dev/input/mice in > /etc/X11/xorg.conf anymore! As long as the new release is considered a "stable" release of the driver, I think it's a very reasonable request. Please file a bug in bugzilla. If it requires both kernel changes and driver changes, be sure to file a separate kernel bug report and a separate linuxwacom package report. If the new driver is dependent on having any kernel changes, be sure to indicate that if you're aware, so that rpm dependencies can be set up correctly. HTH -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From jwboyer at jdub.homelinux.org Tue Jan 10 18:36:31 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 10 Jan 2006 12:36:31 -0600 (CST) Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <1136888676.8026.48.camel@greebo> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> Message-ID: <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> > On Tue, 2006-01-10 at 03:57 -0600, Dennis Gilmore wrote: >> Once upon a time Tuesday 10 January 2006 3:29 am, Build System wrote: >> > New package sqlite2 >> > Embeddable SQL engine in a C library >> >> Was the extras maintainer notifies first? > > Unfortunately no. The same is true for gmime and lcms. I'm very sorry > about this, but for obvious reasons we couldn't talk about this openly > until all the decision were made, and then things turned into a horrible > rush as I had to get this stuff into the tree before test2 got frozen. Ok, here's some questions that pop into my mind. Note that they are not about whether or not to include mono, but rather the method in which it was included. 1) Why was there a rush to get it into test2? It seems to me that it introduces a bit of instability into a distro that is suppose to be stablizing between test releases. Could this have waited until FC6? 2) Why did it go into Core as opposed to Extras? We're normally trying to move things out of Core. If you want to make an argument about keeping Mono itself in Core, I'm sure folks will listen. But why do beagle, f-spot, etc need to be in Core? 3) Why all the hush-hush stuff and have it magically appear? I'm sure many would like to see an announcement about why it's ok to include now... josh From caillon at redhat.com Tue Jan 10 18:37:24 2006 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 10 Jan 2006 13:37:24 -0500 Subject: Where's the NetworkManger applet in rawhide? In-Reply-To: <43C3DEBD.9030702@uindy.edu> References: <1136840009.2774.19.camel@remedyz.boston.redhat.com> <43C32799.4030406@uindy.edu> <1136871283.4199.9.camel@localhost.localdomain> <43C3DEBD.9030702@uindy.edu> Message-ID: <43C3FEE4.3080504@redhat.com> On 01/10/2006 11:20 AM, D Canfield wrote: > Dan Williams wrote: > >> On Mon, 2006-01-09 at 22:18 -0500, D Canfield wrote: >> >> >>> Just out of curiosity... is there any particular reason this >>> continues to be something that has to be manually added? Couldn't >>> it be added to Add to Panel menu? >> >> Because it's not a panel applet; it's a Notification Area applet. If >> you have session-saving enabled, and you run /usr/bin/nm-applet, the >> applet will stick around. If you don't have session saving enabled, you >> can add it to your "Startup Programs" tab in gnome-session-properties >> (System->Preferences->More Preferences->Sessions) and it will show up. >> >> > I understand the technical difference... but what's the difference for > the end-user? The user should not have to start it. Period. Things should work. It should be there by default. That is the plan for FC5. From jkeating at j2solutions.net Tue Jan 10 18:42:29 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 10 Jan 2006 13:42:29 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> Message-ID: <1136918550.3116.3.camel@ender> On Tue, 2006-01-10 at 12:36 -0600, Josh Boyer wrote: > 1) Why was there a rush to get it into test2? It seems to me that it > introduces a bit of instability into a distro that is suppose to be > stablizing between test releases. Could this have waited until FC6? Very very little gets added after Test2. We wanted testing done on it, and waiting to FC6 is just too far off. > 2) Why did it go into Core as opposed to Extras? We're normally trying > to move things out of Core. If you want to make an argument about keeping > Mono itself in Core, I'm sure folks will listen. But why do beagle, > f-spot, etc need to be in Core? There are some gnome features, such as search stuff, that require beagle, which requires mono. We may see more and more of gnome make use of mono stuff, so it makes sense to be in core for now. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) From jspaleta at gmail.com Tue Jan 10 18:44:13 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 10 Jan 2006 13:44:13 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> Message-ID: <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> On 1/10/06, Josh Boyer wrote: > 2) But why do beagle, > f-spot, etc need to be in Core? if f-spot is in... is gthumb going to be moved out as overlapping functionality? I'd prefer one or the other... but not both in Core. I have no dog in the "best of breed image management" race lets just pick one and then move the other one into Extras. Beagle seems particularly unique in terms of functionality so i don't see an obvious application overlap. -jef"okay wtf... beagle requires xpdf.... lame...very very lame"spaleta From tromey at redhat.com Tue Jan 10 20:03:32 2006 From: tromey at redhat.com (Tom Tromey) Date: 10 Jan 2006 13:03:32 -0700 Subject: Fedora Directory Server in rawhide/FC5? In-Reply-To: <1136911765.22873.26.camel@localhost> References: <20051204144144.GA2312@neu.nirvana> <43C3E440.3020002@redhat.com> <1136911765.22873.26.camel@localhost> Message-ID: >>>>> "Richard" == Richard Hughes writes: >> It probably needs more work before getting into FC. Maybe FC6. Richard> Doesn't it still need a non-free java? Lillian did a lot of work to make these tools work on Classpath. My understanding is that they work but that there are still some minor GUI issues -- swing is still the rawest part of the class library. I don't think anybody has tried them with gcj 4.1 yet. Tom From tadams-lists at myrealbox.com Tue Jan 10 21:43:41 2006 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 10 Jan 2006 14:43:41 -0700 Subject: Mono [Re: rawhide report: 20060110 changes] In-Reply-To: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> Message-ID: <1136929421.2455.6.camel@aurora.localdomain> Okay, I am actually glad this happened. However, I have two gripes. Why was 1.13 not included? It is newer and fixes several problems? Second, and likely an extras issue, can ikvm and monodevelop please be packaged (along with every other part of mono that FC doesn't pick up)? Nice job everyone. Trever Adams -- "Honor isn't about making the right choices. It's about dealing with the consequences." -- Midori Koto From paul at all-the-johnsons.co.uk Tue Jan 10 22:04:18 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 10 Jan 2006 22:04:18 +0000 Subject: Mono [Re: rawhide report: 20060110 changes] In-Reply-To: <1136929421.2455.6.camel@aurora.localdomain> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136929421.2455.6.camel@aurora.localdomain> Message-ID: <1136930658.8335.5.camel@T7.Linux> Hi, > Second, and likely an extras issue, can ikvm and monodevelop please be > packaged (along with every other part of mono that FC doesn't pick up)? monodevelop relies on gtk-sharp being compiled with vte-sharp. vte is currently broken and so this can't be done until it's fixed. TTFN Paul -- main(t,_,a) char*a;{return!0 References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136929421.2455.6.camel@aurora.localdomain> <1136930658.8335.5.camel@T7.Linux> Message-ID: <1136931659.2455.8.camel@aurora.localdomain> On Tue, 2006-01-10 at 22:04 +0000, Paul F. Johnson wrote: > Hi, > > > Second, and likely an extras issue, can ikvm and monodevelop please be > > packaged (along with every other part of mono that FC doesn't pick up)? > > monodevelop relies on gtk-sharp being compiled with vte-sharp. vte is > currently broken and so this can't be done until it's fixed. > > TTFN > > Paul > -- Ok, it does however rely on ikvm according to Novel's packages. But the vte bit makes sense. Thank you, Trever -- "In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away." -- RFC1925: The Twelve Networking Truths From paul at all-the-johnsons.co.uk Tue Jan 10 22:27:10 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Tue, 10 Jan 2006 22:27:10 +0000 Subject: Mono [Re: rawhide report: 20060110 changes] In-Reply-To: <1136931659.2455.8.camel@aurora.localdomain> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136929421.2455.6.camel@aurora.localdomain> <1136930658.8335.5.camel@T7.Linux> <1136931659.2455.8.camel@aurora.localdomain> Message-ID: <1136932030.8335.13.camel@T7.Linux> Hi, > Ok, it does however rely on ikvm according to Novel's packages. But the > vte bit makes sense. I know it does on vte, but ikvm? From memory, ikvm is a java vm for mono. It's not required to build monodevelop (I've never needed and have been building mono from source for well over a year now - to be honest, you're better off with a csharp emacs mode than monodevelop). TTFN Paul -- main(t,_,a) char*a;{return!0 References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136929421.2455.6.camel@aurora.localdomain> <1136930658.8335.5.camel@T7.Linux> <1136931659.2455.8.camel@aurora.localdomain> <1136932030.8335.13.camel@T7.Linux> Message-ID: <1136933521.2448.1.camel@aurora.localdomain> On Tue, 2006-01-10 at 22:27 +0000, Paul F. Johnson wrote: > Hi, > > > Ok, it does however rely on ikvm according to Novel's packages. But the > > vte bit makes sense. > > I know it does on vte, but ikvm? From memory, ikvm is a java vm for > mono. It's not required to build monodevelop (I've never needed and have > been building mono from source for well over a year now - to be honest, > you're better off with a csharp emacs mode than monodevelop). > > TTFN > > Paul Alright, when I went to remove ikvm monodevelop said it needed it. Again, based on Novel's packages. So, bogus dependency I guess. To be honest, I have hated emacs since day one of my Linux usage. I don't really know why, just do. (And no, I am not a huge monodevelop fan but have found it useful at times.) Trever -- "The Master doesn't talk, he acts. When his work is done, the people say, 'Amazing: we did it, all by ourselves!'" -- Lao-tzu From igorm5 at vip.hr Tue Jan 10 22:54:48 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Tue, 10 Jan 2006 23:54:48 +0100 Subject: Pirut problem Message-ID: <43C43B38.9000500@vip.hr> It seems that all the mirrors are up2date so I manage to upgrade my Rawhide system. I wanted to test Pirut, but it won't start. Here's the output: Component: Software Manager Summary: TB7016490f repos.py:628:get:RepoError: failure: repodata/primary.xml.gz from updates-released: [Errno 256] No more mirrors to try. Traceback (most recent call last): File "/usr/sbin/pirut", line 373, in ? main() File "/usr/sbin/pirut", line 368, in main pm = PackageManager() File "/usr/sbin/pirut", line 82, in __init__ GraphicalYumBase.__init__(self) File "/usr/lib/python2.4/site-packages/pirut/GraphicalYum.py", line 375, in __init__ self.doSackSetup() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 282, in doSackSetup self.repos.populateSack(which=repos) File "/usr/lib/python2.4/site-packages/yum/repos.py", line 286, in populateSack xml = repo.getPrimaryXML() File "/usr/lib/python2.4/site-packages/yum/repos.py", line 795, in getPrimaryXML return self._retrieveMD('primary') File "/usr/lib/python2.4/site-packages/yum/repos.py", line 782, in _retrieveMD cache=self.http_caching == 'all') File "/usr/lib/python2.4/site-packages/yum/repos.py", line 628, in get raise Errors.RepoError, "failure: %s from %s: %s" % (relative, self.id, e) RepoError: failure: repodata/primary.xml.gz from updates-released: [Errno 256] No more mirrors to try. Local variables in innermost frame: e: [Errno 256] No more mirrors to try. prxy: None url: None text: None self: updates-released cache: True reget: None relative: repodata/primary.xml.gz headers: None checkfunc: (>, ('primary',), {}) copy_local: 1 end: None local: //var/cache/yum/updates-released/primary.xml.gz start: None ----------------------------------------------------------------------- Thanks, cheers! -- Igor Jagec From seg at haxxed.com Tue Jan 10 23:18:07 2006 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 10 Jan 2006 17:18:07 -0600 Subject: bittorrent in core? what frontend? In-Reply-To: <1136887652.8026.40.camel@greebo> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <20051220202121.GA11608@devserv.devel.redhat.com> <1136887652.8026.40.camel@greebo> Message-ID: <1136935089.9121.3.camel@localhost> Hey, I just noticed this turn up in Debian: http://www.ruinedsoft.com/freeloader/ I haven't actually tried it yet, but its a GNOME download manager that supports torrents and appears to have a nice simple clean UI. From igorm5 at vip.hr Tue Jan 10 23:29:35 2006 From: igorm5 at vip.hr (Igor Jagec) Date: Wed, 11 Jan 2006 00:29:35 +0100 Subject: Pirut problem In-Reply-To: <43C43B38.9000500@vip.hr> References: <43C43B38.9000500@vip.hr> Message-ID: <43C4435F.5080808@vip.hr> Hm... It works now, and I did nothing to make it work, it start working just like that (?). As I can see, the program is in early stage of development but it looks very nice thoe. Cheers! ------------------------------------------------------------------------ Igor Jagec wrote > It seems that all the mirrors are up2date so I manage to upgrade my > Rawhide system. I wanted to test Pirut, but it won't start. Here's the > output: > > Component: Software Manager > Summary: TB7016490f repos.py:628:get:RepoError: failure: > repodata/primary.xml.gz from updates-released: [Errno 256] No more > mirrors to try. > > Traceback (most recent call last): > File "/usr/sbin/pirut", line 373, in ? > main() > File "/usr/sbin/pirut", line 368, in main > pm = PackageManager() > File "/usr/sbin/pirut", line 82, in __init__ > GraphicalYumBase.__init__(self) > File "/usr/lib/python2.4/site-packages/pirut/GraphicalYum.py", line > 375, in __init__ > self.doSackSetup() > File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 282, in > doSackSetup > self.repos.populateSack(which=repos) > File "/usr/lib/python2.4/site-packages/yum/repos.py", line 286, in > populateSack > xml = repo.getPrimaryXML() > File "/usr/lib/python2.4/site-packages/yum/repos.py", line 795, in > getPrimaryXML > return self._retrieveMD('primary') > File "/usr/lib/python2.4/site-packages/yum/repos.py", line 782, in > _retrieveMD > cache=self.http_caching == 'all') > File "/usr/lib/python2.4/site-packages/yum/repos.py", line 628, in get > raise Errors.RepoError, "failure: %s from %s: %s" % (relative, > self.id, e) > RepoError: failure: repodata/primary.xml.gz from updates-released: > [Errno 256] No more mirrors to try. > > Local variables in innermost frame: > e: [Errno 256] No more mirrors to try. > prxy: None > url: None > text: None > self: updates-released > cache: True > reget: None > relative: repodata/primary.xml.gz > headers: None > checkfunc: ( instance at 0xb7949fac>>, ('primary',), {}) > copy_local: 1 > end: None > local: //var/cache/yum/updates-released/primary.xml.gz > start: None > ----------------------------------------------------------------------- > > Thanks, cheers! > -- Igor Jagec From seandarcy2 at gmail.com Tue Jan 10 23:34:55 2006 From: seandarcy2 at gmail.com (sean) Date: Tue, 10 Jan 2006 18:34:55 -0500 Subject: yum update gone bad today? In-Reply-To: <43C284CB.2040906@redhat.com> References: <1136493357.2462.8.camel@aurora.localdomain> <1136817346.2197.5.camel@athlon2000> <43C284CB.2040906@redhat.com> Message-ID: Rahul Sundaram wrote: > William Lovaton wrote: > >> I wonder what that file is for... can someone elaborate on that? >> according to rpm that file belongs to glibc package. >> >> Thanks, >> >> -William >> > Name service configuration file. man nssswitch.conf for details. > I read the man page. There's nothing that would suggest it would break yum. And I'm still amazed anyone knew they were connected! If I didn't know it was a feature, I'd think it was a ... :) sean From davej at redhat.com Tue Jan 10 23:54:07 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 10 Jan 2006 18:54:07 -0500 Subject: SATA Suspend Kernel Patch In-Reply-To: <43C3E0B0.6030702@uindy.edu> References: <43C33BAA.1010502@uindy.edu> <43C3E0B0.6030702@uindy.edu> Message-ID: <20060110235407.GE3704@redhat.com> On Tue, Jan 10, 2006 at 11:28:32AM -0500, D Canfield wrote: > D Canfield wrote: > > >Is there any chance we're going to see the SATA Suspend kernel patch > >included in FC5 (BZ 169201)? I don't understand what the holdup is > >from it getting into Linus's tree (he's asked someone to submit it to > >him), but every other major distro seems to be using it successfully > >and it seems like one of the test releases would be a good time to try > >it if there's concern about it's stability. Just wondering if anyone > >knew the status. > > > >Thanks > >DC > > > Following up, the thinkwiki suggests that this patch is now in the > kernel 2.6.16 development. So now the patch is "blessed." Maybe it can > wait for 2.6.16 to be rolled in, but my concern is now with timing. > Will kernel updates be rolled in all through FC development, or will > there be a stabilizing point at which the kernel needs to freeze (more > than just a week or two before release, I mean)? We considered stopping at .15 and letting things simmer for a few weeks to nail down any problems, but from initial impressions, .15 isn't particularly stable (especially in the VM dept), and there's a bunch of .16rc bits that we'll definitly want in FC5 (sky2, sata suspend, various other driver updates) so rebasing to .16rc after test2 isn't a painfully hard decision to make. We froze at .15 for test2 because the first few snapshots after a point release are usually way too bumpy, and then even out over time. For those who want to live on the razors edge, my page at http://people.redhat.com/davej/kernels/Fedora/devel should have the latest upstream snapshot based kernels that will go out to rawhide post-test2. > And more generally, will FC5 be as aggressive with updates (both kernel > and otherwise) as FC4, or was that a special circumstance due to the > long development window for FC5? Just curious. It'll continue to rebase to newer upstream point releases, as previous FC releases have. Dave From ellson at research.att.com Wed Jan 11 00:16:08 2006 From: ellson at research.att.com (John Ellson) Date: Tue, 10 Jan 2006 19:16:08 -0500 Subject: loading module for usb joystick? hal bug? Message-ID: <43C44E48.2000508@research.att.com> I just bought a new Logitech usb joystick to use with FlightGear and it works on today's rawhide :-) However I had to manually "modprobe joydev". Shouldn't hal be doing this? Should I bugzilla this against hal? John From saddateh at gmail.com Wed Jan 11 01:55:12 2006 From: saddateh at gmail.com (Sadda Teh) Date: Tue, 10 Jan 2006 20:55:12 -0500 Subject: xorg crashing on x86_64 Message-ID: After latest rawhide update, xorg no longer starts up. From the log: (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jan 10 20:42:01 2006 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Videocard0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) FontPath set to "unix/:7100" (==) RgbPath set to "/usr/lib/X11/rgb" (==) ModulePath set to "/usr/lib64/xorg/modules" Couldn't open RGB_DB '/usr/lib/X11/rgb' (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.8 X.Org XInput driver : 0.5 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (WW) Warning, couldn't open module bitmap (II) UnloadModule: "bitmap" (EE) Failed to load module "bitmap" (module does not exist, 0) (II) LoadModule: "pcidata" (II) Loading /usr/lib64/xorg/modules/libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 6.99.99.902, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.8 Fatal server error: Unable to load required base modules, Exiting... (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor Also, yum emitted an error (something about -e compilation error or something along these lines) when it updated xorg-x11-xfs. My system is an Athlon 64 3200+, motherboard is an Asus A8N-VM (NForce 410 with integrated GeForce 6100). Also, here's a snip from /var/log/messages: Jan 10 20:38:12 codebeast gdm[2255]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Jan 10 20:38:16 codebeast gdm[2270]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Jan 10 20:38:20 codebeast gdm[2282]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Jan 10 20:38:20 codebeast gdm[2223]: deal_with_x_crashes: Running the XKeepsCrashing script Jan 10 20:38:28 codebeast gdm[2223]: Failed to start X server several times in a short time period; disabling display :0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Wed Jan 11 02:21:03 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 10 Jan 2006 21:21:03 -0500 Subject: boot hang with 2.6.15 In-Reply-To: <1136899106.3185.5.camel@xpc.home.erwinrol.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136899106.3185.5.camel@xpc.home.erwinrol.com> Message-ID: <20060111022103.GJ3704@redhat.com> On Tue, Jan 10, 2006 at 02:18:26PM +0100, Erwin Rol wrote: > On Tue, 2006-01-10 at 04:29 -0500, Build System wrote: > > > kernel-2.6.15-1.1826.2.9_FC5 > > ---------------------------- > > * Mon Jan 09 2006 Dave Jones > > - Remove vm debug patch that triggers too easily right now. > > (Needs fixing properly post test2). > > - kill blk_attempt_merge() which was horribly broken. > > - dm: avoid ovvrun while syncing. > > > > * Mon Jan 09 2006 David Woodhouse > > - Fix some usblp problems, add ieee1284_id to sysfs > > - update bcm43xx driver to version tested in -HEAD > > > After my vacation i updated my rawhide machine and it doesn't want to > boot the new kernel. The boot hangs after the line; > > io scheduler cfg registered > > Only a hard reset helps at that point. > > The last working kernel I have is 2.6.14-1.1773_FC5. Gah, was this in bugzilla ? That was a few weeks back, so there's quite a bit to go through there. For test2, it's probably a bit late now, so your best bet is going to be to try and find a workaround (maybe playing with elevator= options). If it's not in bugzilla yet, please file one, and boot with 'initcall_debug' and see what the last line it prints is, and drop that into the bugreport. Dave From ivg2 at cornell.edu Wed Jan 11 07:33:06 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 11 Jan 2006 00:33:06 -0700 Subject: Slow refresh: nautilus Message-ID: <43C4B4B2.9070404@cornell.edu> Hi, you might remember I wrote about patterned slowdown over the GNOME desktop last week. Since then my superblock was corrupted, the entire root partition was lost, and I had to reinstall (twice). On the bright side, the new Fedora system is much faster than before, and does not suffer from the slowdown issue. I am using the latest kernel now, with the oss nv driver. But... I do see a strange issue, that I don't think is normal. When switching from a maximized app to an empty workspace, redraw of the background is particularly slow - it takes about 1 sec on Athlon 1600+. During that time the icons disappear. This might not seem slow, but it gets really annoying. The CPU spikes to 100% every time. I see the same thing when opening new folders in nautilus. I don't use nautilus for file management, but I imagine this would be really annoying for those that do. (as an aside, I am trying to test this w/ fullscreen folders, but the spatial feature that remembers where each folder was opened and how large it is doesn't seem to work currently) Is anyone else seeing the same issue..... I was not seeing this before, but I was using the accelerated nvidia driver. From pemboa at gmail.com Wed Jan 11 07:55:57 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 11 Jan 2006 01:55:57 -0600 Subject: In search of a PyGtk and Glade tutorial Message-ID: <16de708d0601102355g77f144edrcf8f4935223fa64c@mail.gmail.com> Hey guys, I want to attempt my first GUI program. I would like to use PyGtk and Glade. RIgth now I am having serious issues understanding the basics of layout with Gtk (the last time I did a GUI app was in Delphi) I am just not gettign the widgets to go into any type of proportion. When I use the box widgets for layout, they seem to immediately take up all the space. So I am looking for recommendation on a Glade tutorial. I have done sone googling, but most of the results i see aren't to actual tutorials. Please advise. I would like to begin contributting but need to develop these skills. Thank you. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at redhat.com Wed Jan 11 09:07:45 2006 From: buildsys at redhat.com (Build System) Date: Wed, 11 Jan 2006 04:07:45 -0500 Subject: rawhide report: 20060111 changes Message-ID: <200601110907.k0B97j6w021654@porkchop.devel.redhat.com> Removed package perseus-dependency Removed package perseus-distribution Removed package jonas Removed package fractal Removed package jonathan-core Removed package p6spy Removed package jakarta-commons-cli Removed package dtdparser Removed package nanoxml Removed package howl-logger Removed package perseus-fos Removed package jorm Removed package asm Removed package perseus-persistence Removed package medor-expression Removed package jotm Removed package oldkilim Removed package objectweb-anttask Removed package perseus-concurrency Removed package gif89encoder Removed package jonathan-jeremie Removed package monolog Removed package perseus-pool Removed package medor Removed package joram Removed package perseus-cache Removed package carol Removed package objectweb-deploysched Removed package jorm-rdb-adapter Removed package gnu.regexp Removed package jonas Updated Packages: GFS-kernel-2.6.14.1-20051219.162641.FC5.8 ----------------------------------------- * Tue Jan 10 2006 Jesse Keating - rebuilt anaconda-10.91.2-1 ------------------ * Tue Jan 10 2006 Jeremy Katz - 10.91.2-1 - fix hard drive installs (pjones) * Tue Jan 10 2006 Jeremy Katz - 10.91.1-1 - more ppc rescue image (jkeating) - actually commit the dmraid fix (pjones) cman-kernel-2.6.14.1-20051219.162641.FC5.9 ------------------------------------------ * Tue Jan 10 2006 Jesse Keating - rebuilt again dlm-kernel-2.6.14.1-20051219.162641.FC5.7 ----------------------------------------- * Tue Jan 10 2006 Jesse Keating - rebuilt fontconfig-2.3.93-3 ------------------- * Tue Jan 10 2006 Bill Nottingham - 2.3.93-3 - prereq coreutils for mkdir/touch in %post gimp-2:2.2.10-2 --------------- * Tue Jan 10 2006 Nils Philippsen - rebuild with lcms * Thu Dec 29 2005 Nils Philippsen - 2.2.10 - version 2.2.10 gstreamer08-0.8.11-3 -------------------- * Tue Jan 10 2006 Bill Nottingham 0.8.11-3 - requires(pre) coreutils, since we call env gtk2-engines-2.7.2-2 -------------------- * Tue Jan 10 2006 Ray Strode 2.7.2-2 - fix handle drawing bugs from F-Spot and gnome-panel - change %makeinstall to make install DESTDIR=... kudzu-1.2.18-1 -------------- * Tue Jan 10 2006 Bill Nottingham - 1.2.18-1 - add missing fchdir in pcmcia code - fix segfault if pcmcia network devices are found before their drivers are loaded (#174341) selinux-policy-2.1.8-3 ---------------------- * Tue Jan 10 2006 Dan Walsh 2.1.8-3 - More Fixes for hal and readahead vte-0.11.16-2.fc5.1 ------------------- * Tue Jan 10 2006 Bill Nottingham 0.11.16-2 - prereq initscripts as it creates the utmp group xen-3.0-0.20060110.fc5.2 ------------------------ * Tue Jan 10 2006 - 3.0-0.20060110.fc5.1 - Update to xen-unstable from 20060110 (cset 8526) xorg-x11-xfs-1:1.0.0-2 ---------------------- * Tue Jan 10 2006 Bill Nottingham 1:1.0.0-2 - fix %post script (#176009, ) Broken deps for i386 ---------------------------------------------------------- gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires kernel-smp = 0:2.6.14-1.1805_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.30.i686 requires /lib/modules/2.6.14-1.1805_FC5smp jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires kernel = 0:2.6.14-1.1805_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.30.x86_64 requires /lib/modules/2.6.14-1.1805_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) From ankit644 at yahoo.com Wed Jan 11 09:13:41 2006 From: ankit644 at yahoo.com (Ankit Patel) Date: Wed, 11 Jan 2006 01:13:41 -0800 (PST) Subject: In search of a PyGtk and Glade tutorial In-Reply-To: <16de708d0601102355g77f144edrcf8f4935223fa64c@mail.gmail.com> Message-ID: <20060111091341.27683.qmail@web34602.mail.mud.yahoo.com> Arthur Pemberton wrote: Hey guys, I want to attempt my first GUI program. I would like to use PyGtk and Glade. RIgth now I am having serious issues understanding the basics of layout with Gtk (the last time I did a GUI app was in Delphi) I am just not gettign the widgets to go into any type of proportion. When I use the box widgets for layout, they seem to immediately take up all the space. So I am looking for recommendation on a Glade tutorial. I have done sone googling, but most of the results i see aren't to actual tutorials. Please advise. I would like to begin contributting but need to develop these skills. Thank you. -- As a boy I jumped through Windows, as a man I play with Penguins. -- Hi Arthur, I think the best way to learn programming for creating packages for Fedora is, read the code of the existing applications. You can select smaller packages like system-config-languages, system-config-mouse to read/understand the behaviour of coding. That's what i did before creating my first package. However, i have some useful links for Python & GTK, which may help you. http://www.pygtk.org/pygtk2reference/index.html http://www.gtk.org/api/2.6/gtk/index.html http://www.pygtk.org/pygtktutorial/index.html Regards, Ankit Patel --------------------------------- Yahoo! Photos ? Showcase holiday pictures in hardcover Photo Books. You design it and we?ll bind it! -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at redhat.com Wed Jan 11 09:28:05 2006 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 11 Jan 2006 10:28:05 +0100 Subject: rawhide report: 20060110 changes In-Reply-To: <43C3DBE6.6050101@zoeloelip.be> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <43C38938.5080901@zoeloelip.be> <1136889068.8026.52.camel@greebo> <43C3DBE6.6050101@zoeloelip.be> Message-ID: <1136971685.8026.72.camel@greebo> On Tue, 2006-01-10 at 17:08 +0100, Bart Vanbrabant wrote: > Alexander Larsson wrote: > > On Tue, 2006-01-10 at 11:15 +0100, Bart Vanbrabant wrote: > > > >> When I start beagle this doesn't work. I started beagled with --fg and > >> I get his error: > >> > > > > I think this is an evolution-sharp vs evolution 2.6 thing. > > > > You can start beagled with --deny-backend EvolutionDataServer. > > > > > I updated the patch in gnome bugzilla but there is still an issue with > the glue library: > > http://bugzilla.gnome.org/show_bug.cgi?id=320190 > I have this all fixed now, although test2 is frozen, so I'm not sure when it will appear. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a gun-slinging ninja vagrant with a secret. She's a radical nymphomaniac mechanic on her way to prison for a murder she didn't commit. They fight crime! From alexl at redhat.com Wed Jan 11 09:33:36 2006 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 11 Jan 2006 10:33:36 +0100 Subject: Mono [Re: rawhide report: 20060110 changes] In-Reply-To: <1136929421.2455.6.camel@aurora.localdomain> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136929421.2455.6.camel@aurora.localdomain> Message-ID: <1136972016.8026.78.camel@greebo> On Tue, 2006-01-10 at 14:43 -0700, Trever L. Adams wrote: > Okay, I am actually glad this happened. However, I have two gripes. Why > was 1.13 not included? It is newer and fixes several problems? Because it was released very very recently. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a fast talking misogynist grifter who hides his scarred face behind a mask. She's a violent paranoid detective from aristocratic European stock. They fight crime! From twaugh at redhat.com Wed Jan 11 09:33:32 2006 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 11 Jan 2006 09:33:32 +0000 Subject: In search of a PyGtk and Glade tutorial In-Reply-To: <20060111091341.27683.qmail@web34602.mail.mud.yahoo.com> References: <16de708d0601102355g77f144edrcf8f4935223fa64c@mail.gmail.com> <20060111091341.27683.qmail@web34602.mail.mud.yahoo.com> Message-ID: <20060111093332.GL16000@redhat.com> On Wed, Jan 11, 2006 at 01:13:41AM -0800, Ankit Patel wrote: > Arthur Pemberton wrote: Hey guys, > > I want to attempt my first GUI program. I would like to use PyGtk > and Glade. RIgth now I am having serious issues understanding the > basics of layout with Gtk (the last time I did a GUI app was in > Delphi) I am just not gettign the widgets to go into any type of > proportion. When I use the box widgets for layout, they seem to > immediately take up all the space. > > So I am looking for recommendation on a Glade tutorial. I have > done sone googling, but most of the results i see aren't to actual > tutorials. I wrote this one a few years ago which might be of some help: http://cyberelk.net/tim/articles/pygtk/pygtk.pdf As for GTK+ widget packing, best is to find a GTK+ tutorial that explains it rather than looking for something specific to the PyGtk Python bindings. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alexl at redhat.com Wed Jan 11 09:38:52 2006 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 11 Jan 2006 10:38:52 +0100 Subject: Mono app packaging In-Reply-To: <43C3E0FD.2040702@conversis.de> References: <43C3E0FD.2040702@conversis.de> Message-ID: <1136972332.8026.82.camel@greebo> On Tue, 2006-01-10 at 17:29 +0100, Dennis Jacobfeuerborn wrote: > Hi, > I noticed that at least in the packages for f-spot and beagle the > executable binaries are located in "/usr/lib//*.exe" and that > "/usr/bin" merely contains stub scripts that call these executables. This > looks quite ugly to me as it defeats the standard filesystem hierarchy so > is this something temporary or is this so kind of "best practice" for mono > applications? This is standard for many types of apps, like those written in python and other scripting languages. Here are some guidlines on how this is supposed to work for mono apps: http://www.mono-project.com/Guidelines:Application_Deployment =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a benighted white trash barbarian fleeing from a secret government programme. She's a vivacious impetuous safe cracker from out of town. They fight crime! From jakub at redhat.com Wed Jan 11 09:41:31 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 11 Jan 2006 04:41:31 -0500 Subject: Mono app packaging In-Reply-To: <1136972332.8026.82.camel@greebo> References: <43C3E0FD.2040702@conversis.de> <1136972332.8026.82.camel@greebo> Message-ID: <20060111094131.GJ7768@devserv.devel.redhat.com> On Wed, Jan 11, 2006 at 10:38:52AM +0100, Alexander Larsson wrote: > On Tue, 2006-01-10 at 17:29 +0100, Dennis Jacobfeuerborn wrote: > > Hi, > > I noticed that at least in the packages for f-spot and beagle the > > executable binaries are located in "/usr/lib//*.exe" and that > > "/usr/bin" merely contains stub scripts that call these executables. This > > looks quite ugly to me as it defeats the standard filesystem hierarchy so > > is this something temporary or is this so kind of "best practice" for mono > > applications? > > This is standard for many types of apps, like those written in python > and other scripting languages. But if [ -e ./Config.exe ] && [ -e ./Makefile.am ] ; then echo "*** Running uninstalled Config.exe ***" THIS_PATH="../Util:../BeagleClient" THIS_EXE="./Config.exe" THIS_FILTERS="../Filters" else THIS_PATH="/usr/lib/beagle:/usr/lib" THIS_EXE="/usr/lib/beagle/Config.exe" fi crap in all the scripts certainly is not the standard for many types of apps. This has no business to be in the installed version of the scripts, there we know we want to run the installed one and really shouldn't change behavior depending on content of the current working directory. Jakub From P at draigBrady.com Wed Jan 11 09:59:23 2006 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Wed, 11 Jan 2006 09:59:23 +0000 Subject: In search of a PyGtk and Glade tutorial In-Reply-To: <16de708d0601102355g77f144edrcf8f4935223fa64c@mail.gmail.com> References: <16de708d0601102355g77f144edrcf8f4935223fa64c@mail.gmail.com> Message-ID: <43C4D6FB.90901@draigBrady.com> Arthur Pemberton wrote: > Hey guys, > > So I am looking for recommendation on a Glade tutorial. I have done > sone googling, but most of the results i see aren't to actual tutorials. > > Please advise. I would like to begin contributting but need to develop > these skills. I would advise looking at existing apps. Here's a talk I did a couple of years back, which contains a couple of simple apps: http://www.pixelbeat.org/talks/pygtk/ P?draig. From mailinglists at erwinrol.com Wed Jan 11 10:29:00 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 11 Jan 2006 11:29:00 +0100 Subject: boot hang with 2.6.15 In-Reply-To: <20060111022103.GJ3704@redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136899106.3185.5.camel@xpc.home.erwinrol.com> <20060111022103.GJ3704@redhat.com> Message-ID: <1136975340.3455.5.camel@xpc.home.erwinrol.com> On Tue, 2006-01-10 at 21:21 -0500, Dave Jones wrote: > On Tue, Jan 10, 2006 at 02:18:26PM +0100, Erwin Rol wrote: > > After my vacation i updated my rawhide machine and it doesn't want to > > boot the new kernel. The boot hangs after the line; > > > > io scheduler cfg registered > > > > Only a hard reset helps at that point. > > > > The last working kernel I have is 2.6.14-1.1773_FC5. > > Gah, was this in bugzilla ? That was a few weeks back, so there's > quite a bit to go through there. The problems with 2.6.14-1.1776_FC5 where a know problem before i left for vacation, and I assume that was fixed. > For test2, it's probably a bit late now, so your best bet is > going to be to try and find a workaround (maybe playing with > elevator= options). If it's not in bugzilla yet, please file one, > and boot with 'initcall_debug' and see what the last line it prints > is, and drop that into the bugreport. OK the debug message I see last is; calling initcall 0xffffffff802127cb pci_init + 0x0/0x2b I assume it is because of the messed up Shuttle BIOS (thank you Shuttle for that master piece of engineering!), but it did work with older kernels so i wonder why it stopped working now. Anny idea where to start looking ? - Erwin From mailinglists at erwinrol.com Wed Jan 11 10:48:19 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 11 Jan 2006 11:48:19 +0100 Subject: boot hang with 2.6.15 In-Reply-To: <1136975340.3455.5.camel@xpc.home.erwinrol.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136899106.3185.5.camel@xpc.home.erwinrol.com> <20060111022103.GJ3704@redhat.com> <1136975340.3455.5.camel@xpc.home.erwinrol.com> Message-ID: <1136976499.2954.0.camel@xpc.home.erwinrol.com> Dave I tried your latest kernel and that has the same problem, it seems to hang in pci_init. - Erwin From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jan 11 12:03:40 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 11 Jan 2006 13:03:40 +0100 Subject: Extra CDs packages installation gone in firstboot? Message-ID: <20060111130340.79e896db@python2> Hi, I just installed the development tree for the first time in a while yesterday, and was a bit surprised and disappointed to see that the firstboot step to install packages from "Extra" CDs was gone (which AFAIK has only ever been used in RHEL). Is it just temporary because of the changes to all the package related tools to use yum as a backend, or is this final? In FC4 it apparently didn't work anyway, so as long as system-cdinstall-helper is still there for installing the same stuff after firstboot, from nautilus using the "autorun" script, it's no big deal anyway. For those curious about why I'm concerned, it's because I've created (finally, I had that in mind for a looong while) a CD for FC4 i386 which includes all freshrpms.net packages, so that users with no or slow Internet connections can nevertheless easily install full-featured multimedia players etc. A bit more information here : http://lists.freshrpms.net/pipermail/freshrpms-list/2006-January/013758.html The current goal was to demonstrate the possibility of creating such a compilation of package, which is now done. But I really think that some specialized CDs (Games, Office, Desktops...) or a big fat DVD of snapshots of Fedora Extras packages would be really nice too... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.14 0.19 0.19 From nicolas.mailhot at laposte.net Wed Jan 11 10:57:08 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jan 2006 11:57:08 +0100 (CET) Subject: Mono app packaging In-Reply-To: <604aa7910601100847k108fc27eg1a47e709429ad4d@mail.gmail.com> References: <43C3E0FD.2040702@conversis.de> <604aa7910601100847k108fc27eg1a47e709429ad4d@mail.gmail.com> Message-ID: <9814.192.54.193.25.1136977028.squirrel@rousalka.dyndns.org> On Mar 10 janvier 2006 17:47, Jeff Spaleta wrote: > On 1/10/06, Dennis Jacobfeuerborn wrote: >> Hi, >> I noticed that at least in the packages for f-spot and beagle the >> executable binaries are located in "/usr/lib//*.exe" and that >> "/usr/bin" merely contains stub scripts that call these executables. >> This >> looks quite ugly to me as it defeats the standard filesystem hierarchy >> so >> is this something temporary or is this so kind of "best practice" for >> mono >> applications? > > I'm not sure what the fuss is about, mozilla and firefox and > openoffice all do this sort of thing already. They are all bigs apps not developped primarily for Linux and trying to change them would be hopeless That's not the case for shining new mono apps -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Jan 11 11:04:41 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jan 2006 12:04:41 +0100 (CET) Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> Message-ID: <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> On Mar 10 janvier 2006 19:44, Jeff Spaleta wrote: > On 1/10/06, Josh Boyer wrote: >> 2) But why do beagle, >> f-spot, etc need to be in Core? > > if f-spot is in... is gthumb going to be moved out as overlapping > functionality? > I'd prefer one or the other... but not both in Core. I have no dog in > the "best of breed image management" race lets just pick one and then > move the other one into Extras. There is one *BIG* difference between gthumb and f-spot gthumb can be used for casual browsing/manipulation of any directory containing image files f-spot can not - in insists in importing/pre-processing ever picture directory before making it available. So it's more a centralised picture management app Till f-spot gets a "casual browsing mode" it's not a real gthumb replacement -- Nicolas Mailhot From nicu_fedora at nicubunu.ro Wed Jan 11 13:06:14 2006 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 11 Jan 2006 15:06:14 +0200 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> Message-ID: <43C502C6.6060006@nicubunu.ro> Nicolas Mailhot wrote: > On Mar 10 janvier 2006 19:44, Jeff Spaleta wrote: > >>On 1/10/06, Josh Boyer wrote: >> >>if f-spot is in... is gthumb going to be moved out as overlapping >>functionality? >>I'd prefer one or the other... but not both in Core. I have no dog in >>the "best of breed image management" race lets just pick one and then >>move the other one into Extras. > > > There is one *BIG* difference between gthumb and f-spot > [snip] > > Till f-spot gets a "casual browsing mode" it's not a real gthumb replacement So this would not make f-spot a more appropriate candidate for extras instead of core? If, for example, we will have a simple BitTorrent GUI in core and the full featured Azureus in extras, why not the same policy for image organizers? -- nicu my hats collection: http://fedora.nicubunu.ro/hats/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From jspaleta at gmail.com Wed Jan 11 13:21:59 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 11 Jan 2006 08:21:59 -0500 Subject: Mono app packaging In-Reply-To: <9814.192.54.193.25.1136977028.squirrel@rousalka.dyndns.org> References: <43C3E0FD.2040702@conversis.de> <604aa7910601100847k108fc27eg1a47e709429ad4d@mail.gmail.com> <9814.192.54.193.25.1136977028.squirrel@rousalka.dyndns.org> Message-ID: <604aa7910601110521qe4c06afv923205ef795d77a9@mail.gmail.com> On 1/11/06, Nicolas Mailhot wrote: > They are all bigs apps not developped primarily for Linux and trying to > change them would be hopeless > > That's not the case for shining new mono apps Fine, you want more examples: /usr/sbin/system-config-network /usr/bin/switchdesk /usr/sbin/gdm I look forward to reading your RFE's in bugzilla asking for these wrapper scripts to be removed. -jef"nothing to see here"spaleta From mpeters at mac.com Wed Jan 11 13:33:36 2006 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 11 Jan 2006 05:33:36 -0800 Subject: Extra CDs packages installation gone in firstboot? In-Reply-To: <20060111130340.79e896db@python2> References: <20060111130340.79e896db@python2> Message-ID: <1136986417.17436.65.camel@locolhost.localdomain> On Wed, 2006-01-11 at 13:03 +0100, Matthias Saou wrote: > > For those curious about why I'm concerned, it's because I've created > (finally, I had that in mind for a looong while) a CD for FC4 i386 which > includes all freshrpms.net packages, so that users with no or slow > Internet connections can nevertheless easily install full-featured > multimedia players etc. I don't know the answer to your question, but that absolutely rocks - I hope it gets put back into Anaconda simply because a lot of people would benefit from that. From clumens at redhat.com Wed Jan 11 15:03:09 2006 From: clumens at redhat.com (Chris Lumens) Date: Wed, 11 Jan 2006 10:03:09 -0500 Subject: Extra CDs packages installation gone in firstboot? In-Reply-To: <20060111130340.79e896db@python2> References: <20060111130340.79e896db@python2> Message-ID: <20060111150309.GD3322@exeter.boston.redhat.com> > I just installed the development tree for the first time in a while > yesterday, and was a bit surprised and disappointed to see that the > firstboot step to install packages from "Extra" CDs was gone (which AFAIK > has only ever been used in RHEL). > > Is it just temporary because of the changes to all the package related > tools to use yum as a backend, or is this final? In FC4 it apparently > didn't work anyway, so as long as system-cdinstall-helper is still there > for installing the same stuff after firstboot, from nautilus using the > "autorun" script, it's no big deal anyway. It's been removed, at least for now, because of all the packaging stuff. The additional CDs module in firstboot actually used system-config-packages for all the hard work, but that program no longer exists. We'll have to either do some work on pirut or firstboot to get that supported again. The relevant comment in the firstboot spec file is: * Wed Nov 16 2005 Chris Lumens 1.3.53-1 - Disable Additional CDs module for now - Chris From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Jan 11 15:09:53 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 11 Jan 2006 16:09:53 +0100 Subject: Extra CDs packages installation gone in firstboot? In-Reply-To: <20060111150309.GD3322@exeter.boston.redhat.com> References: <20060111130340.79e896db@python2> <20060111150309.GD3322@exeter.boston.redhat.com> Message-ID: <20060111160953.6db24f1d@python2> Chris Lumens wrote : > > I just installed the development tree for the first time in a while > > yesterday, and was a bit surprised and disappointed to see that the > > firstboot step to install packages from "Extra" CDs was gone (which AFAIK > > has only ever been used in RHEL). > > > > Is it just temporary because of the changes to all the package related > > tools to use yum as a backend, or is this final? In FC4 it apparently > > didn't work anyway, so as long as system-cdinstall-helper is still there > > for installing the same stuff after firstboot, from nautilus using the > > "autorun" script, it's no big deal anyway. > > It's been removed, at least for now, because of all the packaging stuff. > The additional CDs module in firstboot actually used > system-config-packages for all the hard work, but that program no longer > exists. We'll have to either do some work on pirut or firstboot to get > that supported again. > > The relevant comment in the firstboot spec file is: > > * Wed Nov 16 2005 Chris Lumens 1.3.53-1 > - Disable Additional CDs module for now Thanks for those details! I see two important reasons to not forget to get the feature back in before FC5 final : - It would be nice for me to still be able to provide compilations of packages on CD or DVD for FC5 (and not just me, Extras for instance), and this right after install from the original FC5 media for users without Internet access. So it can't be re-added in an update. - RHEL5 will definitely use this (ipw2x00 firmwares etc.), so if the next RHEL is based on FC5 as time lines seem to suggest, it'll be required. Anyway, I'll focus testing other aspects of FC development for now, then. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.02 0.17 0.23 From ndbecker2 at gmail.com Wed Jan 11 15:09:45 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 11 Jan 2006 10:09:45 -0500 Subject: FAT patent uphelp, now what? Message-ID: If FAT patent is upheld, then I guess FAT support has to be removed. From paul at all-the-johnsons.co.uk Wed Jan 11 15:13:56 2006 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 11 Jan 2006 15:13:56 +0000 Subject: FAT patent uphelp, now what? In-Reply-To: References: Message-ID: <1136992436.1164.32.camel@mrwibble.mrwobble> Hi, > If FAT patent is upheld, then I guess FAT support has to be removed. I have a feeling it will be appealed again. FAT is not a novel or non-obvious format - file allocation tables have been used since the inception of SCSI drives and even as far back (home use) as 1984 with the Sinclair ZX Microdrive and BBC "floopy" drives. TTFN Pal -- "Logic, my dear Zoe, is merely the ability to be wrong with authority" - Dr Who From jspaleta at gmail.com Wed Jan 11 15:16:51 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 11 Jan 2006 10:16:51 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> Message-ID: <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> On 1/11/06, Nicolas Mailhot wrote: > gthumb can be used for casual browsing/manipulation of any directory > containing image files Aren't there other ways already in Core to casually browse directories of images? Doesn't nautilus provide some functionality for casual viewing of images via eog? > f-spot can not - in insists in importing/pre-processing ever picture > directory before making it available. So it's more a centralised picture > management app And i think a default application that is more centralized and more focused is very much consistent with previous fedora core functionality decisions. f-spot is to photos as rhythmbox is to music > Till f-spot gets a "casual browsing mode" it's not a real gthumb replacement The question as to Core/Extras is never about feature-for-feature replacements. It's never about most features either. The question is prioritization of functionality. You can not deny that there is significant overlap here between these applications and general function. The question becomes what is the primary functionality that Fedora Core is attempting to fill and how well does each candidate application fill that role. As to the question of which functionality is more important.. casual browsing or centralized management. I'm not really sure casual browsing of images outside of the filemanager is that important compared to centralized photo management at this point. I do however feel strongly that a choice needs to be made and one of these applications should be in Core, and the other should move to Extras. eog,gthumb,f-spot i do not think all 3 should be in Core. -jef From caillon at redhat.com Wed Jan 11 15:17:17 2006 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 11 Jan 2006 10:17:17 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> Message-ID: <43C5217D.3010408@redhat.com> On 01/11/2006 06:04 AM, Nicolas Mailhot wrote: > > There is one *BIG* difference between gthumb and f-spot > > gthumb can be used for casual browsing/manipulation of any directory > containing image files > > f-spot can not - in insists in importing/pre-processing ever picture > directory before making it available. So it's more a centralised picture > management app > > Till f-spot gets a "casual browsing mode" it's not a real gthumb replacement > > You're assuming that a directory viewer (which we already have in nautilus, though it is not targeted to just images) is more valuable to the image user than a centralized app. In other words, before trying to replace functionality, first ask whether the functionality was really useful to begin with. For most people, the answer is not really. The end user thinks in terms of time, not directory structure on a disk. "Those photos from last summer's vacation" instead of "those photos i uploaded somewhere onto my machine, lets see not here... i thought they were here... well ... they are around here somewhere". If you want to browse file/directory structures, use nautilus. Gthumb isn't that good of a nautilus replacement anyway. From n0dalus+redhat at gmail.com Wed Jan 11 15:19:18 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 12 Jan 2006 01:49:18 +1030 Subject: FAT patent uphelp, now what? In-Reply-To: References: Message-ID: <6280325c0601110719w7a441fc2w4695315835488303@mail.gmail.com> On 1/12/06, Neal Becker wrote: > If FAT patent is upheld, then I guess FAT support has to be removed. > I think the patents in question are only to do with simultaneously supporting 8.3 filenames and long filenames. If that's correct then we would only have to remove that particular part of the code (if that functionality even exists on Linux vfat) since it's not really needed anyway. n0dalus. From jspaleta at gmail.com Wed Jan 11 15:26:44 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 11 Jan 2006 10:26:44 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <43C5217D.3010408@redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <43C5217D.3010408@redhat.com> Message-ID: <604aa7910601110726h18700369i6165d571c9fc981a@mail.gmail.com> On 1/11/06, Christopher Aillon wrote: > You're assuming that a directory viewer (which we already have in > nautilus, though it is not targeted to just images) is more valuable to > the image user than a centralized app. In other words, before trying to > replace functionality, first ask whether the functionality was really > useful to begin with. For most people, the answer is not really. I can hold up my wife as an example of your analysis of how a "normal user" wants to interact with photos. She goes through the trouble of booting back into windows to use picasa because of its photo management capabilities. It will be interesting to see if f-spot means the functionality bar to make booting into windows no longer worth the effort. -jef From n0dalus+redhat at gmail.com Wed Jan 11 15:30:21 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 12 Jan 2006 02:00:21 +1030 Subject: Rawhide Reports Message-ID: <6280325c0601110730n782b6e78we2cce58652ee2e64@mail.gmail.com> Hi, Is there a centralized location (ie, website) to see all the latest changelog entries for applications in fedora-development? The daily rawhide reports are ok, but I'd like to do per-app viewing of changes as well as per-day (and sometimes the rawhide reports are missing). This would be great because people could test new features and check that bugs are fixed, etc. Alternatively, or as well as, is there somewhere that shows specific things that need to be tested at the moment? (Particularly in regard to FC5 test releases) Thanks, n0dalus. From sundaram at redhat.com Wed Jan 11 15:32:28 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 11 Jan 2006 21:02:28 +0530 Subject: Rawhide Reports In-Reply-To: <6280325c0601110730n782b6e78we2cce58652ee2e64@mail.gmail.com> References: <6280325c0601110730n782b6e78we2cce58652ee2e64@mail.gmail.com> Message-ID: <43C5250C.8070807@redhat.com> n0dalus wrote: >Hi, > >Is there a centralized location (ie, website) to see all the latest >changelog entries for applications in fedora-development? The daily >rawhide reports are ok, but I'd like to do per-app viewing of changes >as well as per-day (and sometimes the rawhide reports are missing). > >This would be great because people could test new features and check >that bugs are fixed, etc. > >Alternatively, or as well as, is there somewhere that shows specific >things that need to be tested at the moment? (Particularly in regard >to FC5 test releases) > >Thanks, >n0dalus. > > http://fedoraproject.org/infofeed/ -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From ndbecker2 at gmail.com Wed Jan 11 16:27:55 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 11 Jan 2006 11:27:55 -0500 Subject: mozilla-config gone in FC5? Message-ID: I'm trying to build vlc. It is looking for mozilla-config. This used to be provided by rpm -q -f /usr/bin/mozilla-config mozilla-nspr-devel-1.7.12-1.5.1 I can't find it for FC5. From mailinglists at erwinrol.com Wed Jan 11 16:53:01 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 11 Jan 2006 17:53:01 +0100 Subject: boot hang with 2.6.15 In-Reply-To: <1136976499.2954.0.camel@xpc.home.erwinrol.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136899106.3185.5.camel@xpc.home.erwinrol.com> <20060111022103.GJ3704@redhat.com> <1136975340.3455.5.camel@xpc.home.erwinrol.com> <1136976499.2954.0.camel@xpc.home.erwinrol.com> Message-ID: <1136998381.3290.3.camel@xpc.home.erwinrol.com> On Wed, 2006-01-11 at 11:48 +0100, Erwin Rol wrote: > Dave I tried your latest kernel and that has the same problem, it seems > to hang in pci_init. I compiled a 2.6.15 Linus kernel with the .config from the fedora kernel and that does boot. It does have some other problems like a oops, but is doesn't hang and userspace seems to work. - Erwin -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.txt.gz Type: application/x-gzip Size: 8050 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed Jan 11 16:53:12 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jan 2006 17:53:12 +0100 (CET) Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <43C5217D.3010408@redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <43C5217D.3010408@redhat.com> Message-ID: <13538.192.54.193.25.1136998392.squirrel@rousalka.dyndns.org> On Mer 11 janvier 2006 16:17, Christopher Aillon wrote: > On 01/11/2006 06:04 AM, Nicolas Mailhot wrote: >> >> There is one *BIG* difference between gthumb and f-spot >> >> gthumb can be used for casual browsing/manipulation of any directory >> containing image files >> >> f-spot can not - in insists in importing/pre-processing ever picture >> directory before making it available. So it's more a centralised picture >> management app >> >> Till f-spot gets a "casual browsing mode" it's not a real gthumb >> replacement >> >> > You're assuming that a directory viewer (which we already have in > nautilus, though it is not targeted to just images) is more valuable to > the image user than a centralized app. No. I'm saying those are two different usage pattern, so "replacing" one with the other is a mistake. If F-Spot covered all major gthumb use case there wouldn't be a problem. As matter stands, it doesn't. (and no when I growse someone else's usb/flash/cd I don't want to import everything in a central db then delete what I don't need. I want to browse first to check if there is something really worth it, and then maybe import some parts of this archive.) Most users do not interact only with their own photo storage. They interact with those of their family, friends, etc. F-Spot assumes there is only one photo archive which is plain wrong. > If you want to > browse file/directory structures, use nautilus. Gthumb isn't that good > of a nautilus replacement anyway. nautilus is next to useless for photo browsing. Like it's next to useless for musinc browsing. For generic file management it's ok. The helix demos were interesting, but who ever used the nautilus views in everyday life ? -- Nicolas Mailhot From sundaram at redhat.com Wed Jan 11 16:57:01 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 11 Jan 2006 22:27:01 +0530 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <13538.192.54.193.25.1136998392.squirrel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <43C5217D.3010408@redhat.com> <13538.192.54.193.25.1136998392.squirrel@rousalka.dyndns.org> Message-ID: <43C538DD.3090209@redhat.com> Hi > The helix demos >were interesting, but who ever used the nautilus views in everyday life ? > > There always is a underlying assumption all the time here that people dont do what you dont you do. Nobody runs pure Fedora repository systems, nobody uses nautilus views ... -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at redhat.com Wed Jan 11 17:00:31 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 11 Jan 2006 22:30:31 +0530 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <13538.192.54.193.25.1136998392.squirrel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <43C5217D.3010408@redhat.com> <13538.192.54.193.25.1136998392.squirrel@rousalka.dyndns.org> Message-ID: <43C539AF.2000600@redhat.com> Hi >No. >I'm saying those are two different usage pattern, so "replacing" one with >the other is a mistake > Its a mistake only when Fedora Core wants to satisfy both usage patterns. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From katzj at redhat.com Wed Jan 11 17:06:03 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 11 Jan 2006 12:06:03 -0500 Subject: Extra CDs packages installation gone in firstboot? In-Reply-To: <20060111160953.6db24f1d@python2> References: <20060111130340.79e896db@python2> <20060111150309.GD3322@exeter.boston.redhat.com> <20060111160953.6db24f1d@python2> Message-ID: <1136999163.693.2.camel@bree.local.net> On Wed, 2006-01-11 at 16:09 +0100, Matthias Saou wrote: > Thanks for those details! I see two important reasons to not forget to get > the feature back in before FC5 final : I definitely want to get it in, but it's mostly a question of if we can get there in time. Here's to hoping ;-) Jeremy From dennis at ausil.us Wed Jan 11 17:08:50 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 11 Jan 2006 11:08:50 -0600 Subject: mozilla-config gone in FC5? In-Reply-To: References: Message-ID: <200601111108.50309.dennis@ausil.us> On Wednesday 11 January 2006 10:27, Neal Becker wrote: > I'm trying to build vlc. It is looking for mozilla-config. This used to > be provided by > rpm -q -f /usr/bin/mozilla-config > mozilla-nspr-devel-1.7.12-1.5.1 > > I can't find it for FC5. try nspr-devel From gianluca.cecchi at gmail.com Wed Jan 11 17:25:14 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Wed, 11 Jan 2006 18:25:14 +0100 Subject: rawhide report: 20060110 changes [extras packages moved to core] Message-ID: <561c252c0601110925p6a2c4382n@mail.gmail.com> On 1/11/06, Jeff Spaleta wrote: >I can hold up my wife as an example of your analysis of how a "normal >user" wants to interact with photos. She goes through the trouble of >booting back into windows to use picasa because of its photo >management capabilities. It will be interesting to see if f-spot means >the functionality bar to make booting into windows no longer worth the >effort. Are there "official" statements about directives for core/extra inclusion? Are kde based packages automatically in extra? If this is not the case, why not include digikam and digikamimageplugins packages for photo management? digiKam employs the gPhoto2 program to communicate with digital still cameras; whith older ones that are not directly supported by gPhoto2, there is support for the Mass Storage protocol (USB and FireWire). I'm using without any problem on my fc5 devel updated at yesterday changes digikam-0.8.0-11.fc5.i386.rpm, digikam-devel-0.8.0-11.fc5.i386.rpm and digikamimageplugins 0.8 (based on digikamimageplugins-0.7.4-9.fc5 spec file after downlaoding source and updating spec file; already contacted mantainer) I think is the best for centralized photo management. See project page at: http://www.digikam.org/ Screenshots at: http://www.digikam.org/?q=image Gianluca From jkeating at j2solutions.net Wed Jan 11 17:30:10 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 11 Jan 2006 12:30:10 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <561c252c0601110925p6a2c4382n@mail.gmail.com> References: <561c252c0601110925p6a2c4382n@mail.gmail.com> Message-ID: <1137000610.5698.7.camel@ender> On Wed, 2006-01-11 at 18:25 +0100, Gianluca Cecchi wrote: > Are there "official" statements about directives for core/extra inclusion? > Are kde based packages automatically in extra? > If this is not the case, why not include digikam and > digikamimageplugins packages for photo management? > digiKam employs the gPhoto2 program to communicate with digital still > cameras; whith older ones that are not directly supported by gPhoto2, > there is support for the Mass Storage protocol (USB and FireWire). > I'm using without any problem on my fc5 devel updated at yesterday changes > digikam-0.8.0-11.fc5.i386.rpm, > digikam-devel-0.8.0-11.fc5.i386.rpm > and digikamimageplugins 0.8 (based on digikamimageplugins-0.7.4-9.fc5 spec file > after downlaoding source and updating spec file; already contacted mantainer) > I think is the best for centralized photo management. > See project page at: > http://www.digikam.org/ > Screenshots at: > http://www.digikam.org/?q=image > Nothing exactly official, however Red Hat (and Fedora) focus on GTK and Gnome as the default and target desktop. All Fedora developed tools are gtk, and thats where the majority of resources go. There is even discussion of releasing KDE into Extras so that the community (which would include internal Red Hat KDE developers/maintainers) could maintain KDE in a more open way. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) From sundaram at redhat.com Wed Jan 11 17:30:20 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 11 Jan 2006 23:00:20 +0530 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <561c252c0601110925p6a2c4382n@mail.gmail.com> References: <561c252c0601110925p6a2c4382n@mail.gmail.com> Message-ID: <43C540AC.7090603@redhat.com> Gianluca Cecchi wrote: >On 1/11/06, Jeff Spaleta wrote: > > >>I can hold up my wife as an example of your analysis of how a "normal >>user" wants to interact with photos. She goes through the trouble of >>booting back into windows to use picasa because of its photo >>management capabilities. It will be interesting to see if f-spot means >>the functionality bar to make booting into windows no longer worth the >>effort. >> >> > >Are there "official" statements about directives for core/extra inclusion? > > There are some generic guidelines http://fedora.redhat.com/projects/desktop/defaults.html http://fedoraproject.org/wiki/Extras/CoreVsExtras There has been ongoing discussions in fedora-maintainers list about defining targets in a better way. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From sundaram at redhat.com Wed Jan 11 17:33:47 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 11 Jan 2006 23:03:47 +0530 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <1137000610.5698.7.camel@ender> References: <561c252c0601110925p6a2c4382n@mail.gmail.com> <1137000610.5698.7.camel@ender> Message-ID: <43C5417B.2070302@redhat.com> Hi > There is even >discussion of releasing KDE into Extras so that the community (which >would include internal Red Hat KDE developers/maintainers) could >maintain KDE in a more open way. > > > This proposal has been captured here http://fedoraproject.org/wiki/KDE -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From d.jacobfeuerborn at conversis.de Wed Jan 11 17:36:59 2006 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Wed, 11 Jan 2006 18:36:59 +0100 Subject: Slow refresh: nautilus In-Reply-To: <43C4B4B2.9070404@cornell.edu> References: <43C4B4B2.9070404@cornell.edu> Message-ID: <43C5423B.9040806@conversis.de> Ivan Gyurdiev wrote: > Hi, you might remember I wrote about patterned slowdown over the GNOME > desktop last week. Since then my superblock was corrupted, the entire > root partition was lost, and I had to reinstall (twice). On the bright > side, the new Fedora system is much faster than before, and does not > suffer from the slowdown issue. I am using the latest kernel now, with > the oss nv driver. > > But... I do see a strange issue, that I don't think is normal. When > switching from a maximized app to an empty workspace, redraw of the > background is particularly slow - it takes about 1 sec on Athlon 1600+. > During that time the icons disappear. This might not seem slow, but it > gets really annoying. The CPU spikes to 100% every time. I see the same > thing when opening new folders in nautilus. I don't use nautilus for > file management, but I imagine this would be really annoying for those > that do. (as an aside, I am trying to test this w/ fullscreen folders, > but the spatial feature that remembers where each folder was opened and > how large it is doesn't seem to work currently) > > Is anyone else seeing the same issue..... > I was not seeing this before, but I was using the accelerated nvidia > driver. > I'm seeing the same things and in my case it has to do with Xorg hitting fallback paths and using the CPU where it should use the on-card blitter. This happens with the radeon driver (on an r300 based card) and the nv driver (on a gforce 2mx). It seems pixmaps are stored in host memory rather than the on-card memory which prevents the blitter from accessing them. Regards, Dennis From nicolas.mailhot at laposte.net Wed Jan 11 17:40:21 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jan 2006 18:40:21 +0100 (CET) Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> Message-ID: <2253.192.54.193.25.1137001221.squirrel@rousalka.dyndns.org> On Mer 11 janvier 2006 16:16, Jeff Spaleta wrote: > On 1/11/06, Nicolas Mailhot wrote: >> gthumb can be used for casual browsing/manipulation of any directory >> containing image files > > Aren't there other ways already in Core to casually browse directories > of images? > Doesn't nautilus provide some functionality for casual viewing of > images via eog? It's not good enough. If you only have 20-30 photos to preview you can do it but you can as well import them in f-spot and delete them afterwards The problem is when you have larger storages to browse (such as the new flash memories that may have been kept in a camera for months, or a picture CD, or whatever) nautilus + eog is insufficient and importing in f-spot just to take a look at them is prohibitive (even on a fast system) >> f-spot can not - in insists in importing/pre-processing ever picture >> directory before making it available. So it's more a centralised picture >> management app > > And i think a default application that is more centralized and more > focused is very much consistent with previous fedora core > functionality decisions. > f-spot is to photos as rhythmbox is to music And rhythmbox is not the only Fedora audio app. You have totem/helixplayer which allow someone to play music without importing it in the rhythmbox db. >> Till f-spot gets a "casual browsing mode" it's not a real gthumb >> replacement > > The question as to Core/Extras is never about feature-for-feature > replacements. It's never about most features either. The question is > prioritization of functionality. You can not deny that there is > significant overlap here between these applications and general > function. Just as there is significant overlap between totem and rhythmbox, gimp and inkscape. In other words, if you simplify the picture too much yes they do the same thing. > The question becomes what is the primary functionality that > Fedora Core is attempting to fill and how well does each candidate > application fill that role. That's an overly restrictive view, esp when we are not talking about packages that weight hundreds of megs like openoffice. Or (in the gthumb case) packages that do not pull in a ton of deps. > As to the question of which functionality is more important.. casual > browsing or centralized management. I'm not really sure casual > browsing of images outside of the filemanager is that important > compared to centralized photo management at this point. It will be soonish. Most people haven't have the time to accumulate big mounds of photos yet, because digital cameras are new. But as soon as they have, well they'll try to exchange photos between their huge photos archives, and the f-spot way of importing the whole photo archive before you can cherry-pick from it is not adapted in this case. (just try to import a few hundred megs of photos, then look at the current flash sizes) Remember, the average user will only zero his flash when he's forced to, ie when it's nearly full. Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Jan 11 17:50:19 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jan 2006 18:50:19 +0100 (CET) Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <43C538DD.3090209@redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <43C5217D.3010408@redhat.com> <13538.192.54.193.25.1136998392.squirrel@rousalka.dyndns.org> <43C538DD.3090209@redhat.com> Message-ID: <10427.192.54.193.25.1137001819.squirrel@rousalka.dyndns.org> On Mer 11 janvier 2006 17:57, Rahul Sundaram wrote: > Hi > >> The helix demos >>were interesting, but who ever used the nautilus views in everyday life ? >> >> > There always is a underlying assumption all the time here that people > dont do what you dont you do. Nobody runs pure Fedora repository > systems, nobody uses nautilus views ... Honestly, if the nautilus views had been successful, why would rhythmbox, totem, gthumb, f-spot heve been developped and included in FC ? Probably some people use them. I doubt the user base is significant. And now I've substanciated my claim, can you substanciate yours ? -- Nicolas Mailhot From sundaram at redhat.com Wed Jan 11 18:01:57 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 11 Jan 2006 23:31:57 +0530 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <10427.192.54.193.25.1137001819.squirrel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <43C5217D.3010408@redhat.com> <13538.192.54.193.25.1136998392.squirrel@rousalka.dyndns.org> <43C538DD.3090209@redhat.com> <10427.192.54.193.25.1137001819.squirrel@rousalka.dyndns.org> Message-ID: <43C54815.1020302@redhat.com> Hi >Honestly, if the nautilus views had been successful, why would rhythmbox, >totem, gthumb, f-spot heve been developped and included in FC ? > >Probably some people use them. I doubt the user base is significant. > >And now I've substanciated my claim, can you substanciate yours ? > > Maybe gthumb, f-spot developers thought they could do a better alternative than nautilus views which might have been good enough for many users anyway. My only claim is that noone use any particular feature it is completely bogus. Nobody knows what percentage of users are using any particular feature at all. We don't even know what packages are being used in Fedora or how many users there are in total. Assumptions about anything like that is merely that, at this point. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From dax at gurulabs.com Wed Jan 11 18:26:58 2006 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 11 Jan 2006 11:26:58 -0700 Subject: Mono app packaging In-Reply-To: <20060111094131.GJ7768@devserv.devel.redhat.com> References: <43C3E0FD.2040702@conversis.de> <1136972332.8026.82.camel@greebo> <20060111094131.GJ7768@devserv.devel.redhat.com> Message-ID: <1137004018.3474.25.camel@mentorng.gurulabs.com> On Wed, 2006-01-11 at 04:41 -0500, Jakub Jelinek wrote: > But > if [ -e ./Config.exe ] && [ -e ./Makefile.am ] ; then > echo "*** Running uninstalled Config.exe ***" > THIS_PATH="../Util:../BeagleClient" > THIS_EXE="./Config.exe" > THIS_FILTERS="../Filters" > else > THIS_PATH="/usr/lib/beagle:/usr/lib" > THIS_EXE="/usr/lib/beagle/Config.exe" > fi > > crap in all the scripts certainly is not the standard for many types of > apps. This has no business to be in the installed version of the scripts, > there we know we want to run the installed one and really shouldn't change > behavior depending on content of the current working directory. Agreed. This is potentially a big security issue, akin to having the current directory in the $PATH (or even worse, first in the $PATH). Dax Kelson Guru Labs From denis at poolshark.org Wed Jan 11 18:40:14 2006 From: denis at poolshark.org (Denis Leroy) Date: Wed, 11 Jan 2006 19:40:14 +0100 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <10427.192.54.193.25.1137001819.squirrel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <43C5217D.3010408@redhat.com> <13538.192.54.193.25.1136998392.squirrel@rousalka.dyndns.org> <43C538DD.3090209@redhat.com> <10427.192.54.193.25.1137001819.squirrel@rousalka.dyndns.org> Message-ID: <43C5510E.8040302@poolshark.org> Nicolas Mailhot wrote: > Honestly, if the nautilus views had been successful, why would rhythmbox, > totem, gthumb, f-spot heve been developped and included in FC ? Well if we took a poll on who thinks rhytymbox or totem are actually useful pieces of software, you might be surprised by the resuls... :-) I personally enjoyed the nautilus views a lot, especially the HTML view which made it possible to very easily and quickly browse through html files. Now that feature is gone forever. -denis From jspaleta at gmail.com Wed Jan 11 18:49:53 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 11 Jan 2006 13:49:53 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <2253.192.54.193.25.1137001221.squirrel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> <2253.192.54.193.25.1137001221.squirrel@rousalka.dyndns.org> Message-ID: <604aa7910601111049i6b4a0964w634cf123ce4425e5@mail.gmail.com> On 1/11/06, Nicolas Mailhot wrote: > And rhythmbox is not the only Fedora audio app. You have totem/helixplayer > which allow someone to play music without importing it in the rhythmbox > db. I have consistently suggested the removal of Helixplayer on what I consider to be strong grounds of duplicate functionality. We can start another thread on this specific topic if you like. Please if anyone has a good technical reason why Helixplayer should continue to be in Core that doesn't invoke an unshippable realmedia codec plugin, please start a side thread. Totem doesn't actually advertise itself as a music player in the menus.. nor in its package description. It advertises itself as a "movie" player. I seriously doubt totem is in the distribution on the strength of its audio playback features. > Just as there is significant overlap between totem and rhythmbox, gimp and > inkscape. In other words, if you simplify the picture too much yes they do > the same thing. inkscape is in Extras and gimp is in Core totem's self-described primary functionality is movie playing and not music. > That's an overly restrictive view, esp when we are not talking about > packages that weight hundreds of megs like openoffice. Or (in the gthumb > case) packages that do not pull in a ton of deps. No.. im talking about the view point of the primary functionality as communicated through mechanisms that users are going to see. Things like the menu entry: Gthumb image viewer (Core) image viewer (eog Core) GQView image viewer (Extras) F-spot photo manager (Core) > It will be soonish. > Most people haven't have the time to accumulate big mounds of photos yet, > because digital cameras are new. My wife has about 8 gigs of photos right now.. i consider that a big mound...and she has chosen on her own to use a mechanism that looks a hell of a lot more like "management" than "browsing." She got so sick of "browsing" that she has resorted to booting into windows to use picasa instead of using gthumb or any other image program available in Fedora Core or Extras because it does a very good job of "managing" and "organizing" photos regardless of location in the diskspace matrix. This isn't the only "not me" user I've watched the usage pattern for. I've had discussions with macusers concerning what they like about iPhoto. The searchable "library" was always something they brought up in the discussion. I honestly have never spoken to anyone... face to face...using any operating system... that had more than 2 gigs of photos that liked browsing photos in a directory/filesystem sense. In my experience talking to "users who are not me" that own and uses a digital camera enough to produce gigs of personal photos has become frustrated with the browse for photos concept and prefer an indexed library approach. > Remember, the average user will only zero his flash when he's forced to, > ie when it's nearly full. I know very well, my wife does this.. and yet she doesn't prefer to "browse".. she prefers to dump and then import into picasa's "library" so she can then "manage" photos into overlapping collections. I seen exactly the usage pattern as an observer and "browsing" is not the chosen technical solution here.. "management" has consistently been the technical solution that the "average user" that I know have reached for. Liberal arts college students to parents with small children.. to retirees with a new fangled digital camera on Alaskan cruises... all have migrated to technical solutions that look a hell of a lot like centralized "management" to index and search their photo collection when they have been given the choice. Now f-spot might really really suck at implementing a good centralized management solution which I'm sure I'll find out is true or not after I introduce my wife to f-spot. But I'm hardpressed to agree with you that "browsing" is what the "average users" I know want to do with their piles of photos. -jef From nicolas.mailhot at laposte.net Wed Jan 11 19:07:58 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jan 2006 20:07:58 +0100 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <43C54815.1020302@redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <43C5217D.3010408@redhat.com> <13538.192.54.193.25.1136998392.squirrel@rousalka.dyndns.org> <43C538DD.3090209@redhat.com> <10427.192.54.193.25.1137001819.squirrel@rousalka.dyndns.org> <43C54815.1020302@redhat.com> Message-ID: <1137006479.15490.22.camel@rousalka.dyndns.org> Le mercredi 11 janvier 2006 ? 23:31 +0530, Rahul Sundaram a ?crit : > We don't even know what > packages are being used in Fedora or how many users there are in total. > Assumptions about anything like that is merely that, at this point. Which is why removing gthumb just because a different app got included is the wrong thing to do. Especially when the package proposed for removal 1. is clean and low-volume 2. does not pull in stupid deps like openmotif, xpdf, or a complete new language stack 3. does not mess with the FHS 4. is properly localised 5. is the one core users know and use 6. provide features the new one does not If anything f-spot should have proven itself into FE before being considered for core. I'm not asking for its removal now it's in. However since f-spot didn't follow the normal review process, it will have to be beaten into shape in core, and before this is done and we know all the pros and cons between f-spot and other core apps arguing for removal of these other apps is way premature (and not very gracious) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Wed Jan 11 19:18:08 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 11 Jan 2006 20:18:08 +0100 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <604aa7910601111049i6b4a0964w634cf123ce4425e5@mail.gmail.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> <2253.192.54.193.25.1137001221.squirrel@rousalka.dyndns.org> <604aa7910601111049i6b4a0964w634cf123ce4425e5@mail.gmail.com> Message-ID: <1137007089.15490.31.camel@rousalka.dyndns.org> Le mercredi 11 janvier 2006 ? 13:49 -0500, Jeff Spaleta a ?crit : > and she has chosen on her own to use a mechanism that looks a > hell of a lot more like "management" than "browsing." So what ? Where did I wrote management was bad or useless ? You're the one who insists it's one or the other. In all your messages you clearly indicate the behaviour of both apps is very different. That makes the whole overlap argument moot IMHO. Unless you have a scientific user study which proves one is better than the other for the overwhelming majority of fedora users. And takes more than one test subject (who haven't even been exposed to f-spot yet if I read you properly) It would have been different if the app you wanted to remove had a significant cost in maintenance, volume or pulled deps. But it's not even the case. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ph18 at cornell.edu Wed Jan 11 19:42:30 2006 From: ph18 at cornell.edu (Paul A Houle) Date: Wed, 11 Jan 2006 14:42:30 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <43C54815.1020302@redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <43C5217D.3010408@redhat.com> <13538.192.54.193.25.1136998392.squirrel@rousalka.dyndns.org> <43C538DD.3090209@redhat.com> <10427.192.54.193.25.1137001819.squirrel@rousalka.dyndns.org> <43C54815.1020302@redhat.com> Message-ID: <43C55FA6.7010109@cornell.edu> Rahul Sundaram wrote: > Maybe gthumb, f-spot developers thought they could do a better > alternative than nautilus views which might have been good enough for > many users anyway. My only claim is that noone use any particular > feature it is completely bogus. Nobody knows what percentage of users > are using any particular feature at all. We don't even know what > packages are being used in Fedora or how many users there are in > total. Assumptions about anything like that is merely that, at this > point. > I've been screwing around a bit with scripts that try to audit what rpms a particular system is using. I've tried two different approaches: (i) do an lsof, find binaries and libraries that are currently loaded, then find out what packages those files are in. (ii) switch on process accouting, and then look up the packages that have had binaries run over a certain period of time. After that, it follows dependencies. Neither one is perfect. (i) gives interesting output for a running server or desktop, but it's just looking at libraries, and in a snapshot in time. (ii) would get almost anything, but it turns out the process accounting code doesn't save the complete path of the binary, so you have to guess the path from the filename. Most of the time looking things up in the $PATH works and isn't ambiguous, except when it is. Most of the things that aren't in the $PATH are cronjobs or init scripts, and those are in predictable places, but this will never work 100% without a different profiling facility (can we set up kprobes to log every file that gets opened?) If you do (ii) you're going to want to include a boot/reboot cycle to get (most) of the long running proccesses that start at boot and end at shutdown. There's also the problem that either method will turn up false positives -- package A requires library B, but the features in library B never get used. Or sadc is running but nobody looks at the sa files because the sysadmin never heard about sa... Here's the output I got from trying method (i) on my RHEL 4 desktop: (the number is a weighted count of how many times a file shows up, also there are plenty of false positives here... I've never used Evolution, for instance, but it shows up, and krb5 is a heavily referenced libraries although I don't use it) 1 bzip2-libs-1.0.2-13.EL4.2 1 Canna-3.7p3-7.EL4 1 Canna-libs-3.7p3-7.EL4 1 cups-1.1.22-0.rc1.9.8 1 cups-libs-1.1.22-0.rc1.9.8 1 cyrus-sasl-gssapi-2.1.19-5.EL4 1 cyrus-sasl-ntlm-2.1.19-5.EL4 1 cyrus-sasl-sql-2.1.19-5.EL4 1 dbus-glib-0.22-12.EL.5 1 dbus-python-0.22-12.EL.5 1 dbus-x11-0.22-12.EL.5 1 dia-0.94-5 1 eel2-2.8.1-2 1 eog-2.8.1-2 1 file-roller-2.8.1-1 1 gdm-2.6.0.5-7.rhel4.4 1 gftp-2.0.17-5 1 glade2-2.6.0-1 1 gnome-applets-2.8.0-5 1 gnome-games-2.8.0-4 1 gnome-system-monitor-2.7.0-2 1 gnome-terminal-2.7.3-2 1 gnome-utils-2.8.0-5 1 gnome-vfs2-smb-2.8.2-8.2 1 gpm-1.20.1-66 1 gthumb-2.4.2-7 1 iiimf-gnome-im-switcher-12.1-13.EL.2 1 iiimf-le-canna-12.1-13.EL.2 1 iiimf-le-chinput-0.3-16 1 iiimf-le-hangul-12.1-13.EL.2 1 iiimf-le-sun-thai-12.1-13.EL.2 1 iiimf-le-unit-12.1-13.EL.2 1 iiimf-le-xcin-0.1.7-11 1 iiimf-libs-12.1-13.EL.2 1 kernel-utils-2.4-13.1.69 1 libattr-2.4.16-3 1 libcap-1.10-20 1 libcroco-0.6.0-4 1 libgsf-1.10.1-1 1 libogg-1.1.2-1 1 librsvg2-2.8.1-1 1 libsepol-1.1.1-2 1 libwnck-2.8.1-1.rhel4.1 1 metacity-2.8.6-2.8 1 mozilla-chat-1.7.12-1.4.1 1 mysql-4.1.12-3.RHEL4.1 1 openssh-server-3.9p1-8.RHEL4.9 1 portmap-4.0-63 1 postgresql-libs-7.4.8-1.RHEL4.1 1 PyXML-0.8.3-6 1 sudo-1.6.7p5-30.1.3 1 system-config-httpd-1.3.1-1 1 tcl-8.4.7-2 1 ttfonts-ja-1.2-36.EL4.0 1 ttfonts-ko-1.0.11-32.2 1 ttfonts-zh_CN-2.14-6 1 udev-039-10.10.EL4 1 up2date-4.4.50-4 1 usermode-gtk-1.74-1 1 vixie-cron-4.1-36.EL4 1 xinetd-2.3.13-4.4E.1 1 xorg-x11-xfs-6.8.2-1.EL.13.20 1 xscreensaver-4.18-5.rhel4.9 2 at-3.1.8-78_EL4 2 bug-buddy-2.8.0-3 2 cyrus-sasl-md5-2.1.19-5.EL4 2 cyrus-sasl-plain-2.1.19-5.EL4 2 db4-4.2.52-7.1 2 emacs-21.3-19.EL.1 2 expect-5.42.1-1 2 gnome-media-2.8.0-3 2 gnome-session-2.8.0-5 2 gnutls-1.0.20-3.2.1 2 gstreamer-0.8.7-4.EL.0 2 hal-0.4.2-1.EL4 2 hesiod-3.0.2-30 2 kdelibs-3.3.1-3.11 2 kdepim-3.3.1-2.1 2 less-382-4 2 libgcc-3.4.4-2 2 libgcrypt-1.2.0-3 2 libgpg-error-1.0-1 2 libsoup-2.2.1-2 2 libtiff-3.6.1-8 2 libungif-4.1.3-1.el4.2 2 lsof-4.72-1.1 2 mozilla-mail-1.7.12-1.4.1 2 sysklogd-1.4.1-26_EL 2 SysVinit-2.85-34.3 2 vnc-server-4.0-8.1 2 Xaw3d-1.5-24 3 coreutils-5.2.1-31.2 3 gedit-2.8.1-4 3 gnome-desktop-2.8.0-5 3 iiimf-server-12.1-13.EL.2 3 kdegraphics-3.3.1-3.4 3 libgnomeprint22-2.8.0-3 3 libvorbis-1.1.0-1 3 nautilus-cd-burner-2.8.3-6 3 nfs-utils-1.0.6-65.EL4 3 urw-fonts-2.2-6.1 4 control-center-2.8.0-12.rhel4.2 4 ncurses-5.4-13 4 perl-5.8.5-16.RHEL4 4 pygtk2-2.4.0-1 4 samba-common-3.0.10-1.4E.2 4 sendmail-8.13.1-2 5 acpid-1.0.3-2 5 dbus-0.22-12.EL.5 5 gstreamer-plugins-0.8.5-1.EL.0 5 libbonoboui-2.8.0.99cvs20040929-2 5 libglade2-2.4.0-5 5 libgnomecanvas-2.8.0-1 5 libgnomeui-2.8.0-1 5 libstdc++-3.4.4-2 5 nautilus-2.8.1-4 5 python-2.3.4-14.1 6 evolution-2.0.2-22 6 filesystem-2.3.0-1 6 kdemultimedia-3.3.1-2 6 mingetty-1.07-3 6 startup-notification-0.7-1 7 audit-libs-1.0.3-6.EL4 7 gamin-0.1.1-3.EL4 7 libpng-1.2.7-1 7 tcp_wrappers-7.6-37.2 8 arts-1.3.1-2 8 cyrus-sasl-2.1.19-5.EL4 8 gnome-panel-2.8.1-3.3E 8 openldap-2.2.13-4 8 pam-0.77-66.13 9 libgnome-2.8.0-2 9 mozilla-nspr-1.7.12-1.4.1 9 mozilla-nss-1.7.12-1.4.1 10 libart_lgpl-2.3.16-3 11 gnome-keyring-0.4.0-1 13 alsa-lib-1.0.6-5.RHEL4 13 audiofile-0.2.6-1 13 esound-0.2.35-2 13 GConf2-2.8.1-1 13 libjpeg-6b-33 13 openssh-clients-3.9p1-8.RHEL4.9 14 atk-1.8.0-2 14 fonts-xorg-base-6.8.1.1-1.EL.1 14 redhat-artwork-0.120.1-1.2E 15 kdebase-3.3.1-5.8 16 libxml2-2.6.16-6 17 evolution-data-server-1.0.2-9 17 popt-1.9.1-11_nonptl 18 ORBit2-2.12.0-3 21 libbonobo-2.8.0-2 21 utempter-0.5.5-5 21 xterm-192-1 22 gnome-vfs2-2.8.2-8.2 22 libselinux-1.19.1-7 25 bash-3.0-19.2 30 fontconfig-2.2.3-7 30 freetype-2.1.9-1 33 e2fsprogs-1.35-12.2.EL4 38 expat-1.95.7-4 46 libtermcap-2.0.8-39 46 openssl-0.9.7a-43.4 48 gtk2-2.4.13-18 53 mozilla-1.7.12-1.4.1 61 zlib-1.2.1.2-1.2 66 pango-1.6.0-9 78 glibc-common-2.3.4-2.13 83 glib2-2.4.7-1 96 krb5-libs-1.3.4-17 500 xorg-x11-libs-6.8.2-1.EL.13.20 730 glibc-2.3.4-2.13 From davej at redhat.com Wed Jan 11 20:33:44 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 11 Jan 2006 15:33:44 -0500 Subject: boot hang with 2.6.15 In-Reply-To: <1136998381.3290.3.camel@xpc.home.erwinrol.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136899106.3185.5.camel@xpc.home.erwinrol.com> <20060111022103.GJ3704@redhat.com> <1136975340.3455.5.camel@xpc.home.erwinrol.com> <1136976499.2954.0.camel@xpc.home.erwinrol.com> <1136998381.3290.3.camel@xpc.home.erwinrol.com> Message-ID: <20060111203344.GB3688@redhat.com> On Wed, Jan 11, 2006 at 05:53:01PM +0100, Erwin Rol wrote: > On Wed, 2006-01-11 at 11:48 +0100, Erwin Rol wrote: > > Dave I tried your latest kernel and that has the same problem, it seems > > to hang in pci_init. > > I compiled a 2.6.15 Linus kernel with the .config from the fedora kernel > and that does boot. It does have some other problems like a oops, but is > doesn't hang and userspace seems to work. ah, x86-64. I'll bet you have an ATI chipset too ? I'm chasing that bug right now. I'll bet booting with pci=noacpi makes it boot for you (though on the system I'm using to test with, that makes it boot, but the network card is useless). If it's the same bug, rest assured, I'm on it.. Dave From zaitcev at redhat.com Wed Jan 11 20:48:59 2006 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 11 Jan 2006 12:48:59 -0800 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> Message-ID: <20060111124859.7adef199.zaitcev@redhat.com> On Wed, 11 Jan 2006 10:16:51 -0500, Jeff Spaleta wrote: > f-spot is to photos as rhythmbox is to music Does this include such features as bugs never being fixed as well? I'm thrilled with anticipation then. -- Pete From jspaleta at gmail.com Wed Jan 11 20:58:25 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 11 Jan 2006 15:58:25 -0500 Subject: mozilla-config gone in FC5? In-Reply-To: References: Message-ID: <604aa7910601111258web4cc91pd3d4ce1334595a53@mail.gmail.com> On 1/11/06, Neal Becker wrote: > I'm trying to build vlc. It is looking for mozilla-config. This used to be > provided by > rpm -q -f /usr/bin/mozilla-config > mozilla-nspr-devel-1.7.12-1.5.1 nspr-devel provides /usr/bin/nspr-config nothing in rawhide currently provides usr/bin/mozilla-config any longer. vlc's build scripts may need to be patched. FYI you can confirm this for yourself with these commands yum --enablerepo=development provides /usr/bin/mozilla-config yum --enablerepo=development provides /usr/bin/nspr-config or on a system with a working repoquery (FC4) repoquery -qf --repoid=development /usr/bin/mozilla-config repoquery -qf --repoid=development /usr/bin/nspr-config -jef From dravet at hotmail.com Wed Jan 11 21:00:54 2006 From: dravet at hotmail.com (Jason Dravet) Date: Wed, 11 Jan 2006 15:00:54 -0600 Subject: why does yelp depend on mozilla? Message-ID: Why does yelp depend on moziila? It is the only application that does. There has been a bug opened since May 2005 to have the dependency updated. Thanks, Jason From mailinglists at erwinrol.com Wed Jan 11 21:02:26 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 11 Jan 2006 22:02:26 +0100 Subject: boot hang with 2.6.15 In-Reply-To: <20060111203344.GB3688@redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136899106.3185.5.camel@xpc.home.erwinrol.com> <20060111022103.GJ3704@redhat.com> <1136975340.3455.5.camel@xpc.home.erwinrol.com> <1136976499.2954.0.camel@xpc.home.erwinrol.com> <1136998381.3290.3.camel@xpc.home.erwinrol.com> <20060111203344.GB3688@redhat.com> Message-ID: <1137013346.2945.11.camel@xpc.home.erwinrol.com> On Wed, 2006-01-11 at 15:33 -0500, Dave Jones wrote: > On Wed, Jan 11, 2006 at 05:53:01PM +0100, Erwin Rol wrote: > > On Wed, 2006-01-11 at 11:48 +0100, Erwin Rol wrote: > > > Dave I tried your latest kernel and that has the same problem, it seems > > > to hang in pci_init. > > > > I compiled a 2.6.15 Linus kernel with the .config from the fedora kernel > > and that does boot. It does have some other problems like a oops, but is > > doesn't hang and userspace seems to work. > > ah, x86-64. I'll bet you have an ATI chipset too ? Yep, a Shuttle ST20G5, the ACPI of this machine seem to be broken like you can see in the dmesg file, for example the follwing lines kind of worry me; .... CPU 0: aperture @ 50000000 size 32 MB Aperture from northbridge cpu 0 too small (32 MB) .... ACPI-0339: *** Error: Looking up [\_SB_.PCI0.LNKC] in namespace, AE_NOT_FOUND search_node ffff81007fe80b88 start_node ffff81007fe80b88 return_node 0000000000000000 ACPI-0339: *** Error: Looking up [\_SB_.PCI0.LNKB] in namespace, AE_NOT_FOUND search_node ffff81007fe8a4a8 start_node ffff81007fe8a4a8 return_node 0000000000000000 .... pcie_portdrv_probe->Dev[5a34:1002] has invalid IRQ. Check vendor BIOS .... pcie_portdrv_probe->Dev[5a38:1002] has invalid IRQ. Check vendor BIOS .... > I'm chasing that bug right now. I'll bet booting with pci=noacpi makes > it boot for you (though on the system I'm using to test with, that makes > it boot, but the network card is useless). No luck, pci=noacpi does not change anything, nor does pci=routeirq and about every other option i tried. For a long time i had to use nohpet to be able to boot, but it seems i changed something in the BIOS settings and now it also boots (the working kernel , not the new 2.6.15 one) also without nohpet. > If it's the same bug, rest assured, I'm on it.. If there is anything i can do to help, let me know. - Erwin -------------- next part -------------- 00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 01) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Unknown device f391 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express Root Port (Slot-) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x16 Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Address: fee00000 Data: 40b1 Capabilities: [b0] #0d [0000] Capabilities: [b8] HyperTransport: MSI Mapping Capabilities: [100] Advanced Error Reporting 00:06.0 PCI bridge: ATI Technologies Inc Unknown device 5a38 (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express Root Port (Slot-) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 3 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch- Link: Speed 2.5Gb/s, Width x1 Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Address: fee00000 Data: 40b9 Capabilities: [b0] #0d [0000] Capabilities: [b8] HyperTransport: MSI Mapping Capabilities: [100] Advanced Error Reporting 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- 00:1c.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI]) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Unknown device f391 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- From sundaram at redhat.com Wed Jan 11 21:06:27 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 12 Jan 2006 02:36:27 +0530 Subject: why does yelp depend on mozilla? In-Reply-To: References: Message-ID: <43C57353.8060105@redhat.com> Jason Dravet wrote: > Why does yelp depend on moziila? It is the only application that > does. There has been a bug opened since May 2005 to have the > dependency updated. > Mozilla needs to separate its core engine from the UI and have the suite, Firefox and applications like Yelp depend on that engine. It's ongoing upstream work. http://developer.mozilla.org/en/docs/XULRunner In the short term maybe Yelp can depend on Firefox but not everyone uses this browser either. You didnt refer to the bug report either. --- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From overholt at redhat.com Wed Jan 11 21:10:28 2006 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 11 Jan 2006 16:10:28 -0500 Subject: why does yelp depend on mozilla? In-Reply-To: References: Message-ID: <1137013828.12656.16.camel@tophat.toronto.redhat.com> On Wed, 2006-01-11 at 15:00 -0600, Jason Dravet wrote: > Why does yelp depend on moziila? It is the only application that does. Eclipse depends upon it for the same reasons as yelp. Andrew From bdpepple at ameritech.net Wed Jan 11 21:15:42 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Wed, 11 Jan 2006 16:15:42 -0500 Subject: why does yelp depend on mozilla? In-Reply-To: <1137013828.12656.16.camel@tophat.toronto.redhat.com> References: <1137013828.12656.16.camel@tophat.toronto.redhat.com> Message-ID: <1137014142.7830.0.camel@shuttle.273piedmont.com> On Wed, 2006-01-11 at 16:10 -0500, Andrew Overholt wrote: > On Wed, 2006-01-11 at 15:00 -0600, Jason Dravet wrote: > > Why does yelp depend on moziila? It is the only application that does. > > Eclipse depends upon it for the same reasons as yelp. Liferea does also. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 dravet at hotmail.com Wed Jan 11 21:22:23 2006 From: dravet at hotmail.com (Jason Dravet) Date: Wed, 11 Jan 2006 15:22:23 -0600 Subject: why does yelp depend on mozilla? Message-ID: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156563 is the bug I was referring to. Thank you Rahul for your nice explaination. Jason From janina at rednote.net Wed Jan 11 21:23:45 2006 From: janina at rednote.net (Janina Sajka) Date: Wed, 11 Jan 2006 16:23:45 -0500 Subject: Checksum Failing (Was Re: More mass rebuilds for GCC) In-Reply-To: <5256d0b0601100759m614c5178se928026f6295fc04@mail.gmail.com> References: <1134891796.5262.19.camel@ender> <20060109123723.641198d7.fedora@wir-sind-cool.org> <5256d0b0601090338j65ebeee2v1faf2f23ac7c346f@mail.gmail.com> <20060109195009.58f4fb31.fedora@wir-sind-cool.org> <5256d0b0601100759m614c5178se928026f6295fc04@mail.gmail.com> Message-ID: <20060111212345.GA7106@rednote.net> Really delighted to see the new compat-libstdc++ today, but getting the following attempting to yum them down: ============================================================================= Install 0 Package(s) Update 2 Package(s) Remove 0 Package(s) Total download size: 405 k Downloading Packages: (1/2): compat-libstdc++-2 100% |=========================| 174 kB 00:00 http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/compat-libstdc%2B%2B-296-2.96-134.i386.rpm: [Errno -1] Package does not match checksum Trying other mirror. (2/2): compat-libstdc++-3 100% |=========================| 230 kB 00:00 http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/compat-libstdc%2B%2B-33-3.2.3-54.fc5.i386.rpm: [Errno -1] Package does not match checksum Trying other mirror. Error Downloading Packages: compat-libstdc++-33 - 3.2.3-54.fc5.i386: failure: Fedora/RPMS/compat-libstdc++-33-3.2.3-54.fc5.i386.rpm from development: [Errno 256] No more mirrors to try. compat-libstdc++-296 - 2.96-134.i386: failure: Fedora/RPMS/compat-libstdc++-296-2.96-134.i386.rpm from development: [Errno 256] No more mirrors to try. Peter Robinson writes: > > > > > As you'll notice, there will be lots more packages bumped for the rebase > > > > > to gcc. Most completed today, but we'll be working through a list of > > > > > failures over the next couple days. Things will still be in a bit of > > > > > flux, but we're working on it. > > > > > > > > > > Java is still being worked on too. Getting the java stack built with > > > > > gcj is a great accomplishment and I really respect our java and gcj team > > > > > for putting in the work to further the free java. Please bare with us > > > > > as we finalize the development changes necessary to accomplish this > > > > > task. > > > > > > > > Does the new GCC introduce any run-time/ABI breakage which requires > > > > packages in Fedora Extras Development to be rebuilt? Or does it only > > > > reveal problematic source code? > > > > > > I think all the extras need to be rebuilt for this. I know seahorse > > > for one needs it (and may need some fixes). > > > > AFAIK, seahorse was affected by SONAME changes in some of its > > dependencies, which made a rebuild necessary. That was a change not > > related to the GCC upgrade. My question is not about ordinary breakage > > through upgrades of dependencies. > > Yes, I think that's true but I also think there is some gcc41 rebuild > issues with it too (well there seems to be when I just try to rebuild > the srpm. I think the binaries produced by gcc 4 and 4.1 are > compatible so most things won't need to be rebuilt, but then its > probably good for them to be rebuilt too. > > Pete > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka Phone: +1.240.715.1272 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://www.ScreenlessPhone.Com to learn more. Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org From jspaleta at gmail.com Wed Jan 11 20:12:53 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 11 Jan 2006 15:12:53 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <1137007089.15490.31.camel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> <2253.192.54.193.25.1137001221.squirrel@rousalka.dyndns.org> <604aa7910601111049i6b4a0964w634cf123ce4425e5@mail.gmail.com> <1137007089.15490.31.camel@rousalka.dyndns.org> Message-ID: <604aa7910601111212i20aa6e1ft46c93a534358568f@mail.gmail.com> On 1/11/06, Nicolas Mailhot wrote: > Le mercredi 11 janvier 2006 ? 13:49 -0500, Jeff Spaleta a ?crit : > > and she has chosen on her own to use a mechanism that looks a > > hell of a lot more like "management" than "browsing." > > So what ? > Where did I wrote management was bad or useless ? > You're the one who insists it's one or the other. In all your messages > you clearly indicate the behaviour of both apps is very different. That > makes the whole overlap argument moot IMHO. If browsing is the important functionality that gthumb is meant to address... nautilus/eog browses and nautilus/eog and gthumb represent duplication. If collection management is the important functionality that gthumb is meant to address... f-spot and gthumb represent duplication. > Unless you have a scientific user study which proves one is better than > the other for the overwhelming majority of fedora users. And takes more > than one test subject (who haven't even been exposed to f-spot yet if I > read you properly) If you want to start claiming scientific user studies is the bar that must be met in this discussion, that's fine with me. I'm more than willing to accept that and avoid the issue of "average user" in this discussion completely. I demand you pony up your scientific study which suggests that that "browsing" functionality is important when you have many photos. I bring up my ancedotal personal experience primarily to counterweight your unsupported claim that browsing is really the preferred way to handle piles of photos. I'll be the pot to your kettle any day of the week. > It would have been different if the app you wanted to remove had a > significant cost in maintenance, volume or pulled deps. But it's not > even the case. Were these factors important when GQView was removed in favor of gthumb? Surely the dependancy list and size of GQView were of similiar burdensome nature. -jef From jspaleta at gmail.com Wed Jan 11 20:58:25 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 11 Jan 2006 15:58:25 -0500 Subject: mozilla-config gone in FC5? In-Reply-To: References: Message-ID: <604aa7910601111258web4cc91pd3d4ce1334595a53@mail.gmail.com> On 1/11/06, Neal Becker wrote: > I'm trying to build vlc. It is looking for mozilla-config. This used to be > provided by > rpm -q -f /usr/bin/mozilla-config > mozilla-nspr-devel-1.7.12-1.5.1 nspr-devel provides /usr/bin/nspr-config nothing in rawhide currently provides usr/bin/mozilla-config any longer. vlc's build scripts may need to be patched. FYI you can confirm this for yourself with these commands yum --enablerepo=development provides /usr/bin/mozilla-config yum --enablerepo=development provides /usr/bin/nspr-config or on a system with a working repoquery (FC4) repoquery -qf --repoid=development /usr/bin/mozilla-config repoquery -qf --repoid=development /usr/bin/nspr-config -jef From heretic at ihug.co.nz Thu Jan 12 01:05:04 2006 From: heretic at ihug.co.nz (David Mohring) Date: Thu, 12 Jan 2006 14:05:04 +1300 Subject: FAT patent uphelp, now what? In-Reply-To: <1136992436.1164.32.camel@mrwibble.mrwobble> References: <1136992436.1164.32.camel@mrwibble.mrwobble> Message-ID: <1137027905.4120.112.camel@heretic.grobb.org> On Wed, 2006-01-11 at 15:13 +0000, Paul F. Johnson wrote: > Hi, > > > If FAT patent is upheld, then I guess FAT support has to be removed. > > I have a feeling it will be appealed again. FAT is not a novel or > non-obvious format - file allocation tables have been used since the > inception of SCSI drives and even as far back (home use) as 1984 with > the Sinclair ZX Microdrive and BBC "floopy" drives. > I am pretty sure that IBM used the same method for storing long names in the allocation table in early OS/2. Microsoft was working with IBM with later releases of OS/2 but the implementation of the "compatible" file system was first done by IBM. -- David Mohring From n0dalus+redhat at gmail.com Thu Jan 12 01:54:41 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 12 Jan 2006 12:24:41 +1030 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <604aa7910601111212i20aa6e1ft46c93a534358568f@mail.gmail.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> <2253.192.54.193.25.1137001221.squirrel@rousalka.dyndns.org> <604aa7910601111049i6b4a0964w634cf123ce4425e5@mail.gmail.com> <1137007089.15490.31.camel@rousalka.dyndns.org> <604aa7910601111212i20aa6e1ft46c93a534358568f@mail.gmail.com> Message-ID: <6280325c0601111754r6ecbeb3bm566fbc22dcee8c@mail.gmail.com> On 1/12/06, Jeff Spaleta wrote: > > If browsing is the important functionality that gthumb is meant to > address... nautilus/eog browses and nautilus/eog and gthumb represent > duplication. > If collection management is the important functionality that gthumb is > meant to address... f-spot and gthumb represent duplication. > IMO, the only one that represents duplication is eog. I figured that was the reason it didn't install by default on my FC5test1 machine. It's still in the repository, which is excellent for those that want it, but keeping it uninstalled by default is a good idea. I don't know if you have actually tried using f-spot, but it is useless. When importing my photos, I told it not to add the photos to it's own ~/Photos folder, but it did it anyway (why do this at all?!). The thumbnail view is horrible; when you click on photos they go blurry. The organizing features are very lacking. I'm sure these things will be fixed in time, but in time for FC5 to be out the door with it as the default and only viewer? I don't think so. I don't think it is a good replacement for gthumb anyway. Gthumb needs two things fixed, and then it will be good. For one, on FC5test, it should be the default handler for images -- not The GIMP. I filed a bug about this (because I think it's just a typo in one of the config files) (1). The other thing that needs improving is that currently gthumb has 2 modes, directory view and single image view; I think it should only have one. When I say single image view, it really is just one image, there are no back/next buttons or slideshows -- it's like eog. Directory view insists on starting up with a screen of thumbnails, with no particular one selected or any particular image 'opened'. Once you do open a picture from directory view, gthumb becomes useful; it's just like single image view except you get slideshow and back/next buttons, as well as a way to jump back to where you were in directory view. This is the mode it should start in (single image, with back/next buttons, and a button to go into thumbnail view). Having a mode for only viewing one image and no other images should be left out for people that want to install eog. 1. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174291 My 2 cents, n0dalus. From nman64 at n-man.com Thu Jan 12 02:10:52 2006 From: nman64 at n-man.com (Patrick Barnes) Date: Wed, 11 Jan 2006 20:10:52 -0600 Subject: Rawhide Reports In-Reply-To: <6280325c0601110730n782b6e78we2cce58652ee2e64@mail.gmail.com> References: <6280325c0601110730n782b6e78we2cce58652ee2e64@mail.gmail.com> Message-ID: <43C5BAAC.9090706@n-man.com> n0dalus wrote: > Hi, > > Is there a centralized location (ie, website) to see all the latest > changelog entries for applications in fedora-development? The daily > rawhide reports are ok, but I'd like to do per-app viewing of changes > as well as per-day (and sometimes the rawhide reports are missing). > > This would be great because people could test new features and check > that bugs are fixed, etc. > You can try viewing the individual changelogs for the packages using ViewCVS. See http://cvs.fedora.redhat.com/ > Alternatively, or as well as, is there somewhere that shows specific > things that need to be tested at the moment? (Particularly in regard > to FC5 test releases) > > Thanks, > n0dalus. > > The new stuff, as seen in the rawhide reports, is always a good place to start. You can also follow up on bugs in Bugzilla or on complaints in the assorted lists and IRC channels. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From canfield at uindy.edu Thu Jan 12 02:17:00 2006 From: canfield at uindy.edu (D Canfield) Date: Wed, 11 Jan 2006 21:17:00 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <6280325c0601111754r6ecbeb3bm566fbc22dcee8c@mail.gmail.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> <2253.192.54.193.25.1137001221.squirrel@rousalka.dyndns.org> <604aa7910601111049i6b4a0964w634cf123ce4425e5@mail.gmail.com> <1137007089.15490.31.camel@rousalka.dyndns.org> <604aa7910601111212i20aa6e1ft46c93a534358568f@mail.gmail.com> <6280325c0601111754r6ecbeb3bm566fbc22dcee8c@mail.gmail.com> Message-ID: <43C5BC1C.4020801@uindy.edu> n0dalus wrote: > Gthumb needs two things fixed, and then it will be good. For one, on > FC5test, it should be the default handler for images -- not The GIMP. > I filed a bug about this (because I think it's just a typo in one of > the config files) I don't much care about the rest of the conversation (doesn't matter much to me either way, as long as software is in extras, I can get to it), but I strongly agree on this point. GIMP as the default image handler was among my top 5 peeves with FC4. DC From buildsys at redhat.com Thu Jan 12 08:00:05 2006 From: buildsys at redhat.com (Build System) Date: Thu, 12 Jan 2006 03:00:05 -0500 Subject: rawhide report: 20060112 changes Message-ID: <200601120800.k0C805eZ002702@porkchop.devel.redhat.com> Removed package jacorb Removed package jonathan-rmi Updated Packages: GFS-kernel-2.6.14.1-20051219.162641.FC5.9 ----------------------------------------- * Wed Jan 11 2006 Jesse Keating - rebuilt again anaconda-10.91.4-1 ------------------ * Wed Jan 11 2006 Jeremy Katz - 10.91.4-1 - Add xen kernels * Wed Jan 11 2006 Jeremy Katz - 10.91.3-1 - remove some unneeded bits from the ppc boot.iso to make it smaller - fix some text display (notting, #177537) - Misc kickstart fixes (clumens) beagle-0.1.4-3 -------------- * Wed Jan 11 2006 Alexander Larsson - 0.1.4-3 - Rebuild with fixed evolution-sharp cman-kernel-2.6.14.1-20051219.162641.FC5.10 ------------------------------------------- * Wed Jan 11 2006 Jesse Keating - and again dlm-kernel-2.6.14.1-20051219.162641.FC5.8 ----------------------------------------- * Wed Jan 11 2006 Jesse Keating - rebuilt again evolution-sharp-0.10.2-3 ------------------------ * Tue Jan 10 2006 Alexander Larsson - 0.10.2-3 - Fix evo 2.6 patch - Add evolibdir pkg-config variable patch from cvs (modified for evo 2.6) f-spot-0.1.5-2 -------------- * Tue Jan 10 2006 Alexander Larsson - 0.1.5-2 - Add lcms depencency gnbd-kernel-2.6.14.0-20051108.134753.FC5.14 ------------------------------------------- * Wed Jan 11 2006 Jesse Keating - rebuilt again * Tue Jan 10 2006 Jesse Keating - rebuilt kernel-2.6.15-1.1826.2.10_FC5 ----------------------------- * Wed Jan 11 2006 Dave Jones - Fix booting issue on x86-64 ATI systems. kernel-xen-2.6.15-1.29_FC5 -------------------------- * Wed Jan 11 2006 - Fix up kevent usage for xen net backend - Fix %post to create mkinitrd for domU libsetrans-0.1.16-1 ------------------- * Wed Jan 11 2006 Dan Walsh 0.1.16-1 - Fix memory corruption error policycoreutils-1.29.5-3 ------------------------ * Tue Jan 10 2006 Dan Walsh 1.29.5-3 - Fixes for mls policy * Tue Jan 10 2006 Dan Walsh 1.29.5-2 - Update semanage and split out seobject - Fix labeleing of home_root pup-0.9.3-1 ----------- * Wed Jan 11 2006 Jeremy Katz - 0.9.3-1 - Fix traceback on update (#177579) - Fix key importing - Give an error message on errors downloading (#177552) - Fix ts checking on second run selinux-policy-2.1.9-2 ---------------------- * Wed Jan 11 2006 Jeremy Katz - 2.1.9-2 - fix pup transitions (#177262) - fix xen disks (#177599) * Tue Jan 10 2006 Dan Walsh 2.1.9-1 - Update to upstream udev-078-4 ---------- * Wed Jan 11 2006 Harald Hoyer - 078-4 - removed group "video" from the rules - fixed specfile - load nvram, floppy, parport and lp modules in /etc/sysconfig/modules/udev-stw.modules until there is a better solution - fixed more floppy module loading Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) From caillon at redhat.com Thu Jan 12 09:01:35 2006 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 12 Jan 2006 04:01:35 -0500 Subject: mozilla-config gone in FC5? In-Reply-To: References: Message-ID: <43C61AEF.2040201@redhat.com> On 01/11/2006 11:27 AM, Neal Becker wrote: > I'm trying to build vlc. It is looking for mozilla-config. This used to be > provided by > rpm -q -f /usr/bin/mozilla-config > mozilla-nspr-devel-1.7.12-1.5.1 vlc should be patched to ask pkg-config for nspr >= 4.6 and failing that, it should ask pkg-config for mozilla-nspr >= 1.7. From mailinglists at erwinrol.com Thu Jan 12 09:12:59 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 12 Jan 2006 10:12:59 +0100 Subject: boot hang with 2.6.15 In-Reply-To: <20060111203344.GB3688@redhat.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136899106.3185.5.camel@xpc.home.erwinrol.com> <20060111022103.GJ3704@redhat.com> <1136975340.3455.5.camel@xpc.home.erwinrol.com> <1136976499.2954.0.camel@xpc.home.erwinrol.com> <1136998381.3290.3.camel@xpc.home.erwinrol.com> <20060111203344.GB3688@redhat.com> Message-ID: <1137057179.2779.0.camel@xpc.home.erwinrol.com> On Wed, 2006-01-11 at 15:33 -0500, Dave Jones wrote: > On Wed, Jan 11, 2006 at 05:53:01PM +0100, Erwin Rol wrote: > ah, x86-64. I'll bet you have an ATI chipset too ? > I'm chasing that bug right now. I'll bet booting with pci=noacpi makes > it boot for you (though on the system I'm using to test with, that makes > it boot, but the network card is useless). > > If it's the same bug, rest assured, I'm on it.. The new 2.6.15-1.1826.2.10_FC5 kernel works. - Erwin From nicolas.mailhot at laposte.net Thu Jan 12 09:24:47 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Jan 2006 10:24:47 +0100 (CET) Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <604aa7910601111212i20aa6e1ft46c93a534358568f@mail.gmail.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> <2253.192.54.193.25.1137001221.squirrel@rousalka.dyndns.org> <604aa7910601111049i6b4a0964w634cf123ce4425e5@mail.gmail.com> <1137007089.15490.31.camel@rousalka.dyndns.org> <604aa7910601111212i20aa6e1ft46c93a534358568f@mail.gmail.com> Message-ID: <43182.192.54.193.35.1137057887.squirrel@rousalka.dyndns.org> On Mer 11 janvier 2006 21:12, Jeff Spaleta wrote: > Were these factors important when GQView was removed in favor of > gthumb? Surely the dependancy list and size of GQView were of similiar > burdensome nature. gqview had the very same model as gthumb (browsing), was badly integrated to gnome, etc -- Nicolas Mailhot From mailinglists at erwinrol.com Thu Jan 12 09:35:21 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 12 Jan 2006 10:35:21 +0100 Subject: rawhide report: 20060112 changes In-Reply-To: <200601120800.k0C805eZ002702@porkchop.devel.redhat.com> References: <200601120800.k0C805eZ002702@porkchop.devel.redhat.com> Message-ID: <1137058521.2779.9.camel@xpc.home.erwinrol.com> When running beagle with --fg I noticed the following error message. ** (IndexHelper:3267): WARNING **: The following assembly referenced from /usr/lib64/beagle/Filters/Filters.dll could not be loaded: Assembly: gsf-sharp (assemblyref_index=11) Version: 0.0.0.5 Public Key: 35e10195dab3c99f The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/usr/lib64/beagle/Filters). When i tried to yum gsf-sharp i got an error that the header was not correct. This is from download.fedora.redhat.com so i assume changing to a mirror will not help. Setting up Install Process Setting up repositories extras-dev: ################################################## 3/3 Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for gsf-sharp to pack into transaction set. gsf-sharp-0.6-4.x86_64.rp 100% |=========================| 5.0 kB 00:00 http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/gsf-sharp-0.6-4.x86_64.rpm: [Errno -1] Header is not complete. Trying other mirror. Error: failure: Fedora/RPMS/gsf-sharp-0.6-4.x86_64.rpm from development: [Errno 256] No more mirrors to try. When trying to yum some other sharp stuff i got more of those messages; http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/debug/gtk-sharp2-debuginfo-2.4.0-2.x86_64.rpm: [Errno -1] Header is not complete. http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/gtk-sharp2-gapi-2.4.0-2.x86_64.rpm: [Errno -1] Header is not complete. http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/gtk-sharp-gapi-1.0.10-3.x86_64.rpm: [Errno -1] Header is not complete. http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/debug/gtk-sharp-debuginfo-1.0.10-3.x86_64.rpm: [Errno -1] Header is not complete. http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/debug/gecko-sharp2-debuginfo-0.11-3.x86_64.rpm: [Errno -1] Header is not complete. Does anybody else see the same problem ? - Erwin From caolanm at redhat.com Thu Jan 12 09:54:29 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 12 Jan 2006 09:54:29 +0000 Subject: OpenOffice.org templates from ooextras Message-ID: <1137059670.23275.14.camel@localhost.localdomain> A probably suitable for fedora extras suggestion is to take a look at http://ooextras.sourceforge.net and grab some of the OpenOffice.org templates there and package them into a set of per-language per-application rpms of sample templates for fedora extras. If anyone is interested in volunteering to do this, bugid http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177205 is open on the topic. C. From nicolas.mailhot at laposte.net Thu Jan 12 09:40:06 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 12 Jan 2006 10:40:06 +0100 (CET) Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <604aa7910601111212i20aa6e1ft46c93a534358568f@mail.gmail.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> <2253.192.54.193.25.1137001221.squirrel@rousalka.dyndns.org> <604aa7910601111049i6b4a0964w634cf123ce4425e5@mail.gmail.com> <1137007089.15490.31.camel@rousalka.dyndns.org> <604aa7910601111212i20aa6e1ft46c93a534358568f@mail.gmail.com> Message-ID: <43153.192.54.193.35.1137058806.squirrel@rousalka.dyndns.org> On Mer 11 janvier 2006 21:12, Jeff Spaleta wrote: > If you want to start claiming scientific user studies is the bar that > must be met in this discussion, that's fine with me No *you* are asking for removal. *you* must back your demand. You started by writing f-spot and gthumb were the same thing. When I pointed they weren't you argued that the gthumb mode was useless and/or was redundant with nautilus. 1. if it is redundant with nautilus why didn't you propose to remove it before ? 2. you still have to prove your assertion that the gthumb mode is useless for most fedora users I don't ask for any change so I don't need to do anything but blow holes in your arguments. Which is rather easy since they boil out to "I pray that with f-spot my wife may not feel obligated to boot into windows to use picasa, and I feel gthumb is useless" -- Nicolas Mailhot From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jan 12 10:06:43 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 Jan 2006 11:06:43 +0100 Subject: HelixPlayer (was: Re: rawhide report: 20060110 changes [extras packages moved to core]) In-Reply-To: <604aa7910601111049i6b4a0964w634cf123ce4425e5@mail.gmail.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> <2253.192.54.193.25.1137001221.squirrel@rousalka.dyndns.org> <604aa7910601111049i6b4a0964w634cf123ce4425e5@mail.gmail.com> Message-ID: <20060112110643.5f66974c@python2> Jeff Spaleta wrote : > On 1/11/06, Nicolas Mailhot wrote: > > And rhythmbox is not the only Fedora audio app. You have totem/helixplayer > > which allow someone to play music without importing it in the rhythmbox > > db. > > I have consistently suggested the removal of Helixplayer on what I > consider to be strong grounds of duplicate functionality. We can start > another thread on this specific topic if you like. Please if anyone > has a good technical reason why Helixplayer should continue to be in > Core that doesn't invoke an unshippable realmedia codec plugin, please > start a side thread. I totally agree regarding HelixPlayer. Can we please move it to Extras, or at least not have it installed by default? I seriously doubt anyone "uses" it, not after trying any other media player. Not only that, but it's very limited in functionality, and from the amount of patching and hacks in the spec file I've seen (in the past, maybe it's gotten better), seems to also be a burden to keep in shape. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.54 0.25 0.15 From jspaleta at gmail.com Thu Jan 12 10:20:10 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 12 Jan 2006 05:20:10 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <43153.192.54.193.35.1137058806.squirrel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> <2253.192.54.193.25.1137001221.squirrel@rousalka.dyndns.org> <604aa7910601111049i6b4a0964w634cf123ce4425e5@mail.gmail.com> <1137007089.15490.31.camel@rousalka.dyndns.org> <604aa7910601111212i20aa6e1ft46c93a534358568f@mail.gmail.com> <43153.192.54.193.35.1137058806.squirrel@rousalka.dyndns.org> Message-ID: <604aa7910601120220h42e473b7jdce53e06c4e721d5@mail.gmail.com> On 1/12/06, Nicolas Mailhot wrote: > 1. if it is redundant with nautilus why didn't you propose to remove it > before ? because I didnt use it to "browse" I i used it for to "manage" via its catalog and library functionality. Since i didn't use its redundant browsing features I didn't fully understand how redundantly redundant it actually was. For what I was attempting to use it for, f-spot overlaps. For what you have described to me as "browsing" functionality that i never used, I feel that nautilus/eog overlap. > 2. you still have to prove your assertion that the gthumb mode is useless > for most fedora users Im very sure i did not at any point assert that browsing was useless. I said i was unsure that it was more important than management. I've ground my arguments in my personal ancedotal experience, I'm not the one throwing hyperbole around. I can't compete with you on that score. > > I don't ask for any change so I don't need to do anything but blow holes > in your arguments. Which is rather easy since they boil out to "I pray > that with f-spot my wife may not feel obligated to boot into windows to > use picasa, and I feel gthumb is useless" I have not until this very post written the word "useless" in this thread. Anyone bothering to keep score and has an active gmail cache can verify that for you if you are incapable of your own fact checking. Please refrain from putting words in my mouth. I'm more than capable of speaking for myself. -jef"Attention OSnews... there's a potential new staff writer in this thread"spaleta From pknirsch at redhat.com Thu Jan 12 11:02:13 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 12 Jan 2006 12:02:13 +0100 Subject: Interesting results for getservbyname() performance (and possible changes for /etc/services) Message-ID: <43C63735.3010609@redhat.com> Hi folks. As i'm now the proud owner of setup i'm planing on doing a major update to /etc/services which has been fairly constant for the past few years with only minor updates. I have downloaded the official IANA list for all registred services and ran a few tests using getservbyname(). The new file is about 20x as big as the old one (580 lines <-> 13604 lines). All searches are repeated 10000 times with this simple app: #include main(int argc, char *argv[]) { struct servent *sv; int i; for (i=0; i< 10000; i++) sv = getservbyname(argv[1], NULL); } Here the results: Unkown service "foobar": old: 7.65user 5.51system 2:06.60elapsed new: 63.99user 10.55system 3:09.55elapsed Known service "svn" (roughly in the middle of both files): old: 1.92user 0.42system 0:02.35elapsed new: 39.91user 3.52system 0:43.43elapsed Known service "ssh" (very early in both files): old: 0.20user 0.27system 0:00.47elapsed new: 0.26user 0.28system 0:00.55elapsed All tests were run on a very current FC-Devel machine (updated yesterday) with a standard NIS/Kerberos configuration. So, what this tells me is that for the unknow service case both are not equally bad but not drastically different. For services in the middle the difference is what i would have expected for uncached linear reads and parsing, roughly 1:20. For very early services though the difference is really neglectable. Now, i know and understand how and why glibc does the getservbyname() call as it does (namely, every time opening, reading and parsing the file). It neither caches calls nor does any other fancy stuff (how could it? The order in the file is arbitrary, so the only possibility is to do a linear read and parse of the file). From what i see though is that, if we use "our" old /etc/services file and just extend it with newer and/or updated services we can only win: Found services will even for the huge new file always be faster than none found ones, and usually an application should search for an existing service. With our old file though i'd suspect that some apps might hit the unkown service fairly often, which are very likely to be in the complete official IANA list and therefore would be speed up with the extension. Another thing that might be worth looking into is to run some analysis what services are most often requested on standard everyday machines and maybe move them more to the front so they get read and parsed earlier. Comments and suggestions are of course always welcome. Oh, and this is not a change i'm planing on doing for FC5, for that it's wayyy to late, so this is all FC6 material. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Kaa's Law: In any sufficiently large group of people most are idiots. From ivazquez at ivazquez.net Thu Jan 12 11:36:01 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 12 Jan 2006 06:36:01 -0500 Subject: Interesting results for getservbyname() performance (and possible changes for /etc/services) In-Reply-To: <43C63735.3010609@redhat.com> References: <43C63735.3010609@redhat.com> Message-ID: <1137065761.5864.10.camel@ignacio.lan> On Thu, 2006-01-12 at 12:02 +0100, Phil Knirsch wrote: > Now, i know and understand how and why glibc does the getservbyname() > call as it does (namely, every time opening, reading and parsing the > file). It neither caches calls nor does any other fancy stuff (how could > it? The order in the file is arbitrary, so the only possibility is to do > a linear read and parse of the file). > Comments and suggestions are of course always welcome. What about writing (or finding) a NS module that does caching? It can pull from a sorted bdb using a binary search, unless /etc/services is newer at which point it rebuilds the database. /etc/services almost *never* changes, so the rebuild speed shouldn't matter too much. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jan 12 12:03:34 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 Jan 2006 13:03:34 +0100 Subject: Compilation problem with gcc 4.1, c++ include files Message-ID: <20060112130334.6474fa2d@python2> Hi, I'm running into a problem while trying to recompile aMule on FC development. I'm not sure what nor who to blame, so I prefer posting here before filing a bug against gcc : [...] configure:6562: checking that wxWidgets has support for large files configure:6576: g++ -E -I/usr/lib64/wx/include/gtk2-unicode-release-2.6 -I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA conftest.cc In file included from /usr/include/wx-2.6/wx/string.h:170, from /usr/include/wx-2.6/wx/memory.h:20, from /usr/include/wx-2.6/wx/object.h:25, from /usr/include/wx-2.6/wx/wx.h:16, from conftest.cc:2: /usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../include/c++/4.1.0/string:44:28: error: bits/c++config.h: No such file or directory [...] In that "string" file there is : #include But /usr/include/c++/4.1.0/bits/c++config.h does not exist, I can only find /usr/include/c++/4.1.0/i386-redhat-linux/bits/c++config.h. This is on x86_64 while trying to rebuild in a mach minimal chroot. Any pointers welcome! Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.39 0.42 0.45 From jakub at redhat.com Thu Jan 12 12:08:39 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 12 Jan 2006 07:08:39 -0500 Subject: Compilation problem with gcc 4.1, c++ include files In-Reply-To: <20060112130334.6474fa2d@python2> References: <20060112130334.6474fa2d@python2> Message-ID: <20060112120839.GT7768@devserv.devel.redhat.com> On Thu, Jan 12, 2006 at 01:03:34PM +0100, Matthias Saou wrote: > [...] > configure:6562: checking that wxWidgets has support for large files > configure:6576: g++ -E -I/usr/lib64/wx/include/gtk2-unicode-release-2.6 > -I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__ > -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA conftest.cc > In file included from /usr/include/wx-2.6/wx/string.h:170, > from /usr/include/wx-2.6/wx/memory.h:20, > from /usr/include/wx-2.6/wx/object.h:25, > from /usr/include/wx-2.6/wx/wx.h:16, > from conftest.cc:2: > /usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../include/c++/4.1.0/string:44:28: > error: bits/c++config.h: No such file or directory > [...] > > In that "string" file there is : > > #include > > But /usr/include/c++/4.1.0/bits/c++config.h does not exist, I can only > find /usr/include/c++/4.1.0/i386-redhat-linux/bits/c++config.h. > > This is on x86_64 while trying to rebuild in a mach minimal chroot. If you are compiling 64-bit stuff, you of course need libstdc++-devel-4.1.0-*.x86_64.rpm installed. From your description it sounds like only libstdc++-devel-4.1.0-*.i386.rpm is installed. Jakub From chabotc at xs4all.nl Thu Jan 12 12:42:43 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Thu, 12 Jan 2006 13:42:43 +0100 Subject: Weird dbus problem when not using GDM (but custom scripts) Message-ID: <1137069763.3567.8.camel@localhost.localdomain> Hi All, i've had a weird dbus problem: Every program was shouting at me it could not determine the address of the dbus daemon. So the first thing i looked at was my hostname and /etc/hosts and it turned out everything was fine there :-) So my second guess was that it would probably be that i bypass all the normal login / gdm stuff and run some custom scripts from inittab: in inittab (runlevel 3): 1:2345:respawn:/usr/bin/x1.sh /usr/bin/x1.sh: #!/bin/bash export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin export PS1="[\u@\h \W]\\$ " export USER=root export HOME=/root unset SHLVL exec bash -l -c "exec /usr/bin/xinit /usr/bin/x2.sh &> /root/.xlog" and /usr/bin/x2.sh: #!/bin/bash cd /root xhost + xrdb -merge /root/.Xresources exec gnome-session Now why run such scripts you might ask .. well i love it that my computer boots up logged in right away, without any logins .. its protected by the front door of my house with locks, so need for all that repetitive password typing, just let me do my business as soon as posible! :-) Also if i have a need to restart X, its just a ctrl-alt-backspace away and i'm automaticly right back in a fresh x session.. just some creature comforts i've grown used to Well it turns out after some googeling that by using such custom shells scripts instead of the propper GDM the dbus envirioment settings were never set that dbus-launch is supposed to set (gnome-session doesn't start it?) So i've modified my x2.sh script into: #!/bin/bash cd /root killall -9 dbus-daemon sleep 1 /usr/bin/dbus-launch --sh-syntax &> /tmp/dbus-env . /tmp/dbus-env rm -f /tmp/dbus-env xhost + xrdb -merge /root/.Xresources exec gnome-session Does this look propper to anyone with some dbus experiance? Everything does seem to work perfect again, so i think so :-) Just weird that gnome-session doesn't take care of this, when its clearly a required part of the gnome session? Is it worth filing any bugs for this, or am i misunderstanding the situation? -- Chris Chabot -------------- 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jan 12 12:45:08 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 Jan 2006 13:45:08 +0100 Subject: Compilation problem with gcc 4.1, c++ include files In-Reply-To: <20060112120839.GT7768@devserv.devel.redhat.com> References: <20060112130334.6474fa2d@python2> <20060112120839.GT7768@devserv.devel.redhat.com> Message-ID: <20060112134508.67d3f07b@python2> Jakub Jelinek wrote : > On Thu, Jan 12, 2006 at 01:03:34PM +0100, Matthias Saou wrote: > > [...] > > configure:6562: checking that wxWidgets has support for large files > > configure:6576: g++ -E -I/usr/lib64/wx/include/gtk2-unicode-release-2.6 > > -I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__ > > -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA conftest.cc > > In file included from /usr/include/wx-2.6/wx/string.h:170, > > from /usr/include/wx-2.6/wx/memory.h:20, > > from /usr/include/wx-2.6/wx/object.h:25, > > from /usr/include/wx-2.6/wx/wx.h:16, > > from conftest.cc:2: > > /usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../include/c++/4.1.0/string:44:28: > > error: bits/c++config.h: No such file or directory > > [...] > > > > In that "string" file there is : > > > > #include > > > > But /usr/include/c++/4.1.0/bits/c++config.h does not exist, I can only > > find /usr/include/c++/4.1.0/i386-redhat-linux/bits/c++config.h. > > > > This is on x86_64 while trying to rebuild in a mach minimal chroot. > > If you are compiling 64-bit stuff, you of course need > libstdc++-devel-4.1.0-*.x86_64.rpm installed. From your description > it sounds like only libstdc++-devel-4.1.0-*.i386.rpm is installed. That's it! Now... try to figure out why mach/yum installed *only* the i386 version in the x86_64 root... $ mach -r fedora-development-x86_64-extras yum list libstdc++-devel Setting up Repos core 100% |=========================| 951 B 00:00 extras 100% |=========================| 1.1 kB 00:00 local 100% |=========================| 951 B 00:00 Reading repository metadata in from local files core : ################################################## 3601/3601 extras : ################################################## 2994/2994 local : ################################################## 8/8 Installed Packages libstdc++-devel.i386 4.1.0-0.14 installed Available Packages libstdc++-devel.x86_64 4.1.0-0.14 core Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.36 0.37 0.33 From rc040203 at freenet.de Thu Jan 12 12:52:46 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 12 Jan 2006 13:52:46 +0100 Subject: Compilation problem with gcc 4.1, c++ include files In-Reply-To: <20060112120839.GT7768@devserv.devel.redhat.com> References: <20060112130334.6474fa2d@python2> <20060112120839.GT7768@devserv.devel.redhat.com> Message-ID: <1137070366.17219.7.camel@mccallum.corsepiu.local> On Thu, 2006-01-12 at 07:08 -0500, Jakub Jelinek wrote: > On Thu, Jan 12, 2006 at 01:03:34PM +0100, Matthias Saou wrote: > > [...] > > configure:6562: checking that wxWidgets has support for large files > > configure:6576: g++ -E -I/usr/lib64/wx/include/gtk2-unicode-release-2.6 > > -I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__ > > -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA conftest.cc > > In file included from /usr/include/wx-2.6/wx/string.h:170, > > from /usr/include/wx-2.6/wx/memory.h:20, > > from /usr/include/wx-2.6/wx/object.h:25, > > from /usr/include/wx-2.6/wx/wx.h:16, > > from conftest.cc:2: > > /usr/lib/gcc/x86_64-redhat-linux/4.1.0/../../../../include/c++/4.1.0/string:44:28: > > error: bits/c++config.h: No such file or directory > > [...] > > > > In that "string" file there is : > > > > #include > > > > But /usr/include/c++/4.1.0/bits/c++config.h does not exist, I can only > > find /usr/include/c++/4.1.0/i386-redhat-linux/bits/c++config.h. > > > > This is on x86_64 while trying to rebuild in a mach minimal chroot. > > If you are compiling 64-bit stuff, you of course need > libstdc++-devel-4.1.0-*.x86_64.rpm installed. From your description > it sounds like only libstdc++-devel-4.1.0-*.i386.rpm is installed. While we're at it, ... Why don't you build GCC with --enable-version-specific-runtime-libs? This would install GCC internal libs and headers such as libstdc++ into "versioned per-target" directories and thereby would allow parallel installation of different versions of GCC and differently targeted GCCs. Ralf From chabotc at xs4all.nl Thu Jan 12 12:56:41 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Thu, 12 Jan 2006 13:56:41 +0100 Subject: Weird dbus problem when not using GDM (but custom scripts) In-Reply-To: <1137069763.3567.8.camel@localhost.localdomain> References: <1137069763.3567.8.camel@localhost.localdomain> Message-ID: <1137070601.1941.2.camel@localhost.localdomain> Woops quick correction to the x2.sh script before anybody is thinking of ever using it, the killall killed the --system dbus to. I've changed my x2.sh to: #!/bin/bash cd /root kill -9 $DBUS_SESSION_BUS_PID &>/dev/null /usr/bin/dbus-launch --sh-syntax &> /tmp/dbus-env echo -e "export DBUS_SESSION_BUS_PID\n" >> /tmp/dbus-env . /tmp/dbus-env rm -f /tmp/dbus-env xhost + xrdb -merge /root/.Xresources exec gnome-session Should work a lot better when not killing the system global dbus :-) On Thu, 2006-01-12 at 13:42 +0100, Chris Chabot wrote: > Hi All, i've had a weird dbus problem: Every program was shouting at me > it could not determine the address of the dbus daemon. > > So the first thing i looked at was my hostname and /etc/hosts and it > turned out everything was fine there :-) > > So my second guess was that it would probably be that i bypass all the > normal login / gdm stuff and run some custom scripts from inittab: > > in inittab (runlevel 3): > 1:2345:respawn:/usr/bin/x1.sh > > /usr/bin/x1.sh: > #!/bin/bash > export > PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin > export PS1="[\u@\h \W]\\$ " > export USER=root > export HOME=/root > unset SHLVL > exec bash -l -c "exec /usr/bin/xinit /usr/bin/x2.sh &> /root/.xlog" > > and /usr/bin/x2.sh: > #!/bin/bash > cd /root > xhost + > xrdb -merge /root/.Xresources > exec gnome-session > > > Now why run such scripts you might ask .. well i love it that my > computer boots up logged in right away, without any logins .. its > protected by the front door of my house with locks, so need for all that > repetitive password typing, just let me do my business as soon as > posible! :-) Also if i have a need to restart X, its just a > ctrl-alt-backspace away and i'm automaticly right back in a fresh x > session.. just some creature comforts i've grown used to > > Well it turns out after some googeling that by using such custom shells > scripts instead of the propper GDM the dbus envirioment settings were > never set that dbus-launch is supposed to set (gnome-session doesn't > start it?) > > So i've modified my x2.sh script into: > #!/bin/bash > cd /root > killall -9 dbus-daemon > sleep 1 > /usr/bin/dbus-launch --sh-syntax &> /tmp/dbus-env > . /tmp/dbus-env > rm -f /tmp/dbus-env > xhost + > xrdb -merge /root/.Xresources > exec gnome-session > > Does this look propper to anyone with some dbus experiance? Everything > does seem to work perfect again, so i think so :-) > > Just weird that gnome-session doesn't take care of this, when its > clearly a required part of the gnome session? > > Is it worth filing any bugs for this, or am i misunderstanding the > situation? > > -- Chris Chabot > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nphilipp at redhat.com Thu Jan 12 13:10:22 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 12 Jan 2006 14:10:22 +0100 Subject: Interesting results for getservbyname() performance (and possible changes for /etc/services) In-Reply-To: <1137065761.5864.10.camel@ignacio.lan> References: <43C63735.3010609@redhat.com> <1137065761.5864.10.camel@ignacio.lan> Message-ID: <1137071422.9970.43.camel@gibraltar.stuttgart.redhat.com> On Thu, 2006-01-12 at 06:36 -0500, Ignacio Vazquez-Abrams wrote: > On Thu, 2006-01-12 at 12:02 +0100, Phil Knirsch wrote: > > Now, i know and understand how and why glibc does the getservbyname() > > call as it does (namely, every time opening, reading and parsing the > > file). It neither caches calls nor does any other fancy stuff (how could > > it? The order in the file is arbitrary, so the only possibility is to do > > a linear read and parse of the file). > > > Comments and suggestions are of course always welcome. > > What about writing (or finding) a NS module that does caching? It can > pull from a sorted bdb using a binary search, unless /etc/services is > newer at which point it rebuilds the database. /etc/services almost > *never* changes, so the rebuild speed shouldn't matter too much. Well, it can't be done this way because NS modules are running with the user's privileges. This would have to be handed off to a daemon with the privileges necessary. 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 From fedora at camperquake.de Thu Jan 12 13:21:18 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 12 Jan 2006 14:21:18 +0100 Subject: Interesting results for getservbyname() performance (and possible changes for /etc/services) In-Reply-To: <1137071422.9970.43.camel@gibraltar.stuttgart.redhat.com> References: <43C63735.3010609@redhat.com> <1137065761.5864.10.camel@ignacio.lan> <1137071422.9970.43.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20060112132118.GA23571@ryoko.camperquake.de> On Thu, Jan 12, 2006 at 02:10:22PM +0100, Nils Philippsen wrote: > Well, it can't be done this way because NS modules are running with the > user's privileges. This would have to be handed off to a daemon with the > privileges necessary. Isn't this exactly what nscd is for? From dwmw2 at infradead.org Thu Jan 12 13:33:01 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 Jan 2006 13:33:01 +0000 Subject: rawhide report: 20060112 changes In-Reply-To: <200601120800.k0C805eZ002702@porkchop.devel.redhat.com> References: <200601120800.k0C805eZ002702@porkchop.devel.redhat.com> Message-ID: <1137072781.4196.241.camel@pmac.infradead.org> On Thu, 2006-01-12 at 03:00 -0500, Build System wrote: > * Wed Jan 11 2006 Jeremy Katz - 10.91.3-1 > - remove some unneeded bits from the ppc boot.iso to make it smaller Pleased to note that you kept /images/netboot/ppc32.img in it -- we actually need that for booting on Pegasos. One thing we could do to shrink it further would be to unify the ramdisk for ppc32 and ppc64 -- the only thing that's different is the modules, and all the userspace stuff is the same (it's all ppc32). How feasible would it be to use the same ramdisk image for both 32-bit and 64-bit installs? -- dwmw2 From jeff at ocjtech.us Thu Jan 12 13:39:54 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 12 Jan 2006 07:39:54 -0600 Subject: rawhide report: 20060112 changes In-Reply-To: <1137058521.2779.9.camel@xpc.home.erwinrol.com> References: <200601120800.k0C805eZ002702@porkchop.devel.redhat.com> <1137058521.2779.9.camel@xpc.home.erwinrol.com> Message-ID: <1137073195.2623.13.camel@lt16585.campus.dmacc.edu> On Thu, 2006-01-12 at 10:35 +0100, Erwin Rol wrote: > > Setting up Install Process > Setting up repositories > extras-dev: ################################################## 3/3 > Reading repository metadata in from local files > Parsing package install arguments > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Downloading header for gsf-sharp to pack into transaction set. > gsf-sharp-0.6-4.x86_64.rp 100% |=========================| 5.0 kB 00:00 > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/gsf-sharp-0.6-4.x86_64.rpm: [Errno -1] Header is not complete. > Trying other mirror. > Error: failure: Fedora/RPMS/gsf-sharp-0.6-4.x86_64.rpm from development: [Errno 256] No more mirrors to try. > > When trying to yum some other sharp stuff i got more of those messages; > > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/debug/gtk-sharp2-debuginfo-2.4.0-2.x86_64.rpm: [Errno -1] Header is not complete. > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/gtk-sharp2-gapi-2.4.0-2.x86_64.rpm: [Errno -1] Header is not complete. > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/gtk-sharp-gapi-1.0.10-3.x86_64.rpm: [Errno -1] Header is not complete. > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/debug/gtk-sharp-debuginfo-1.0.10-3.x86_64.rpm: [Errno -1] Header is not complete. > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/debug/gecko-sharp2-debuginfo-0.11-3.x86_64.rpm: [Errno -1] Header is not complete. > > Does anybody else see the same problem ? Yes, I've seen these error messages. Try running "yum clean all" - that's what fixed it for me... Jeff -------------- 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 ndbecker2 at gmail.com Thu Jan 12 13:40:10 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 12 Jan 2006 08:40:10 -0500 Subject: add --enable-libsuffix=64 Message-ID: I've been testing FC5T1, and as I'm building some kde packages, I seem to need to add --enable-libsuffix=64. Probably because X moved. Why not add this to standard rpmflags? Seems harmless. From rc040203 at freenet.de Thu Jan 12 13:50:12 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 12 Jan 2006 14:50:12 +0100 Subject: add --enable-libsuffix=64 In-Reply-To: References: Message-ID: <1137073812.17219.13.camel@mccallum.corsepiu.local> On Thu, 2006-01-12 at 08:40 -0500, Neal Becker wrote: > I've been testing FC5T1, and as I'm building some kde packages, I seem to > need to add --enable-libsuffix=64. Probably because X moved. > > Why not add this to standard rpmflags? Because this option is not covered by any standards. > Seems harmless. Useless ;) Ralf From mailinglists at erwinrol.com Thu Jan 12 13:54:42 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 12 Jan 2006 14:54:42 +0100 Subject: rawhide report: 20060112 changes In-Reply-To: <1137073195.2623.13.camel@lt16585.campus.dmacc.edu> References: <200601120800.k0C805eZ002702@porkchop.devel.redhat.com> <1137058521.2779.9.camel@xpc.home.erwinrol.com> <1137073195.2623.13.camel@lt16585.campus.dmacc.edu> Message-ID: <1137074082.2883.1.camel@xpc.home.erwinrol.com> On Thu, 2006-01-12 at 07:39 -0600, Jeffrey C. Ollie wrote: > On Thu, 2006-01-12 at 10:35 +0100, Erwin Rol wrote: > Yes, I've seen these error messages. Try running "yum clean all" - > that's what fixed it for me... > after a yum clean all i still get an error message; (1/1): gsf-sharp-0.6-4.x8 100% |=========================| 39 kB 00:01 http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/gsf-sharp-0.6-4.x86_64.rpm: [Errno -1] Package does not match checksum Trying other mirror. Error Downloading Packages: gsf-sharp - 0.6-4.x86_64: failure: Fedora/RPMS/gsf-sharp-0.6-4.x86_64.rpm from development: [Errno 256] No more mirrors to try. - Erwin From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jan 12 14:02:37 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 Jan 2006 15:02:37 +0100 Subject: rawhide report: 20060112 changes In-Reply-To: <1137074082.2883.1.camel@xpc.home.erwinrol.com> References: <200601120800.k0C805eZ002702@porkchop.devel.redhat.com> <1137058521.2779.9.camel@xpc.home.erwinrol.com> <1137073195.2623.13.camel@lt16585.campus.dmacc.edu> <1137074082.2883.1.camel@xpc.home.erwinrol.com> Message-ID: <20060112150237.09729da3@python2> Erwin Rol wrote : > On Thu, 2006-01-12 at 07:39 -0600, Jeffrey C. Ollie wrote: > > On Thu, 2006-01-12 at 10:35 +0100, Erwin Rol wrote: > > > Yes, I've seen these error messages. Try running "yum clean all" - > > that's what fixed it for me... > > > > after a yum clean all i still get an error message; > > (1/1): gsf-sharp-0.6-4.x8 100% |=========================| 39 kB 00:01 > http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/gsf-sharp-0.6-4.x86_64.rpm: [Errno -1] Package does not match checksum > Trying other mirror. > > > Error Downloading Packages: > gsf-sharp - 0.6-4.x86_64: failure: Fedora/RPMS/gsf-sharp-0.6-4.x86_64.rpm from development: [Errno 256] No more mirrors to try. I got that today too on my local mirror for all the packages I was trying to install in a mach root. Only re-running "createrepo" on my mirror server to overwrite the original "repodata" got it to work again. Maybe the current metadata is corrupt... I just thought my FC4 yum was too old or something. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.12 0.50 0.41 From n0dalus+redhat at gmail.com Thu Jan 12 14:22:53 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Fri, 13 Jan 2006 00:52:53 +1030 Subject: Rawhide Reports In-Reply-To: <43C5BAAC.9090706@n-man.com> References: <6280325c0601110730n782b6e78we2cce58652ee2e64@mail.gmail.com> <43C5BAAC.9090706@n-man.com> Message-ID: <6280325c0601120622i17692a6xfdda5eb9939426d@mail.gmail.com> On 1/12/06, Patrick Barnes wrote: > You can try viewing the individual changelogs for the packages using > ViewCVS. See http://cvs.fedora.redhat.com/ Thanks. I also worked out yesterday I could do `rpm -q --changelog package` -- I really wish I had known about that before. > The new stuff, as seen in the rawhide reports, is always a good place to > start. You can also follow up on bugs in Bugzilla or on complaints in > the assorted lists and IRC channels. > I hope that before the test cycle is over there will be a lot more organization in regard to what needs to be tested. Is it worth making a wiki page, a #fedora-testing irc channel, etc? Thanks, n0dalus. From chabotc at xs4all.nl Thu Jan 12 14:39:53 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Thu, 12 Jan 2006 15:39:53 +0100 Subject: rawhide report: 20060112 changes In-Reply-To: <1137073195.2623.13.camel@lt16585.campus.dmacc.edu> References: <200601120800.k0C805eZ002702@porkchop.devel.redhat.com> <1137058521.2779.9.camel@xpc.home.erwinrol.com> <1137073195.2623.13.camel@lt16585.campus.dmacc.edu> Message-ID: <1137076793.21086.1.camel@localhost.localdomain> Same problem here while trying to yum install some packages, using various mirrors .. I was lucky enough to find one with valid (old?) data to proceed with installing, but it seems there's been some distribution of bad meta data I did try the yum clean all, and that didn't fix anything, seems to be a mirror data problem > [Errno -1] Header is not complete. > > > > Does anybody else see the same problem ? > > Yes, I've seen these error messages. Try running "yum clean all" - > that's what fixed it for me... > > Jeff -------------- 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 rdieter at math.unl.edu Thu Jan 12 15:13:53 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Jan 2006 09:13:53 -0600 Subject: add --enable-libsuffix=64 In-Reply-To: References: Message-ID: <43C67231.8060902@math.unl.edu> Neal Becker wrote: > I've been testing FC5T1, and as I'm building some kde packages, I seem to > need to add --enable-libsuffix=64. Probably because X moved. Every libsuffix problem I've seen wrt kde apps had to do with qt, and was solved by defining QTINC/QTLIB, which is done now by qt-devel's /etc/profile.d/qt.(sh|csh) Perhaps if you could post more details, we could help more instead of merely speculating... (-: -- Rex From ndbecker2 at gmail.com Thu Jan 12 15:28:37 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 12 Jan 2006 10:28:37 -0500 Subject: add --enable-libsuffix=64 References: <43C67231.8060902@math.unl.edu> Message-ID: Rex Dieter wrote: > Neal Becker wrote: >> I've been testing FC5T1, and as I'm building some kde packages, I seem to >> need to add --enable-libsuffix=64. Probably because X moved. > > Every libsuffix problem I've seen wrt kde apps had to do with qt, and > was solved by defining QTINC/QTLIB, which is done now by qt-devel's > /etc/profile.d/qt.(sh|csh) > > Perhaps if you could post more details, we could help more instead of > merely speculating... (-: > > -- Rex > Sure. I grabbed the latest krename-3.0.10 tar, and after minor editing to krename.spec included in the tar (copyright->license) try build: + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info ... checking for X... libraries /usr/lib, headers . Nope, that won't work! If I add --enable-libsuffix=64: checking for X... libraries /usr/lib64, headers . This seems to happen on several kde packages I tried. I believe it is because of relocation of X from /usr/X11R6/lib64 to /usr/X11R6. I think kde packages had been fixed to look in /usr/X11R6/lib64, but now they would all need to be fixed to look in /usr/lib64 for X libs? From nphilipp at redhat.com Thu Jan 12 15:36:54 2006 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 12 Jan 2006 16:36:54 +0100 Subject: Interesting results for getservbyname() performance (and possible changes for /etc/services) In-Reply-To: <20060112132118.GA23571@ryoko.camperquake.de> References: <43C63735.3010609@redhat.com> <1137065761.5864.10.camel@ignacio.lan> <1137071422.9970.43.camel@gibraltar.stuttgart.redhat.com> <20060112132118.GA23571@ryoko.camperquake.de> Message-ID: <1137080215.9970.48.camel@gibraltar.stuttgart.redhat.com> On Thu, 2006-01-12 at 14:21 +0100, Ralf Ertzinger wrote: > On Thu, Jan 12, 2006 at 02:10:22PM +0100, Nils Philippsen wrote: > > > Well, it can't be done this way because NS modules are running with the > > user's privileges. This would have to be handed off to a daemon with the > > privileges necessary. > > Isn't this exactly what nscd is for? nscd can't (or at least doesn't) take advantage of knowing about local file changes, it caches information for a certain time period and it doesn't seem to cache services, only passwd, group, hosts. 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 From katzj at redhat.com Thu Jan 12 15:39:09 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 12 Jan 2006 10:39:09 -0500 Subject: rawhide report: 20060112 changes In-Reply-To: <1137072781.4196.241.camel@pmac.infradead.org> References: <200601120800.k0C805eZ002702@porkchop.devel.redhat.com> <1137072781.4196.241.camel@pmac.infradead.org> Message-ID: <1137080349.9891.4.camel@bree.local.net> On Thu, 2006-01-12 at 13:33 +0000, David Woodhouse wrote: > On Thu, 2006-01-12 at 03:00 -0500, Build System wrote: > > * Wed Jan 11 2006 Jeremy Katz - 10.91.3-1 > > - remove some unneeded bits from the ppc boot.iso to make it smaller > > Pleased to note that you kept /images/netboot/ppc32.img in it -- we > actually need that for booting on Pegasos. I did actually look to see what the mkisofs invocations used :-P > One thing we could do to shrink it further would be to unify the ramdisk > for ppc32 and ppc64 -- the only thing that's different is the modules, > and all the userspace stuff is the same (it's all ppc32). > > How feasible would it be to use the same ramdisk image for both 32-bit > and 64-bit installs? It doesn't end up helping much. The vast majority of the initrd is the per-kernel modules. By going with a single initrd, we increase the memory overhead significantly which I'd rather avoid Jeremy From fedora at camperquake.de Thu Jan 12 15:39:02 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 12 Jan 2006 16:39:02 +0100 Subject: Interesting results for getservbyname() performance (and possible changes for /etc/services) In-Reply-To: <1137080215.9970.48.camel@gibraltar.stuttgart.redhat.com> References: <43C63735.3010609@redhat.com> <1137065761.5864.10.camel@ignacio.lan> <1137071422.9970.43.camel@gibraltar.stuttgart.redhat.com> <20060112132118.GA23571@ryoko.camperquake.de> <1137080215.9970.48.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20060112153902.GB23571@ryoko.camperquake.de> On Thu, Jan 12, 2006 at 04:36:54PM +0100, Nils Philippsen wrote: > nscd can't (or at least doesn't) take advantage of knowing about local > file changes, it caches information for a certain time period and it > doesn't seem to cache services, only passwd, group, hosts. AFAIK nscd can cache everything going through nsswitch.conf, including services. From rdieter at math.unl.edu Thu Jan 12 15:40:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Jan 2006 09:40:17 -0600 Subject: add --enable-libsuffix=64 (or --with-extra-libs={%_libdir} ) In-Reply-To: References: <43C67231.8060902@math.unl.edu> Message-ID: <43C67861.3030608@math.unl.edu> Neal Becker wrote: > Rex Dieter wrote: > > >>Neal Becker wrote: >> >>>I've been testing FC5T1, and as I'm building some kde packages, I seem to >>>need to add --enable-libsuffix=64. Probably because X moved. >> >>Every libsuffix problem I've seen wrt kde apps had to do with qt, and >>was solved by defining QTINC/QTLIB, which is done now by qt-devel's >>/etc/profile.d/qt.(sh|csh) >> >>Perhaps if you could post more details, we could help more instead of >>merely speculating... (-: >> >>-- Rex >> > > > Sure. I grabbed the latest krename-3.0.10 tar, and after minor editing to > krename.spec included in the tar (copyright->license) try build: > > + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu > --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr > --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc > --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 > --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com > --mandir=/usr/share/man --infodir=/usr/share/info > ... > checking for X... libraries /usr/lib, headers . > > Nope, that won't work! > > If I add --enable-libsuffix=64: > > checking for X... libraries /usr/lib64, headers . > > This seems to happen on several kde packages I tried. I believe it is OK, looks like your diagnosis was right, though I'd argue that ./configure is broken. It *should* look in what was passed by --libdir=... Another (cleaner, IMO) workaround is to add to configure: --with-extra-libs=%{_libdir} -- Rex From dwmw2 at infradead.org Thu Jan 12 15:47:13 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 Jan 2006 15:47:13 +0000 Subject: rawhide report: 20060112 changes In-Reply-To: <1137080349.9891.4.camel@bree.local.net> References: <200601120800.k0C805eZ002702@porkchop.devel.redhat.com> <1137072781.4196.241.camel@pmac.infradead.org> <1137080349.9891.4.camel@bree.local.net> Message-ID: <1137080834.3085.1.camel@localhost.localdomain> On Thu, 2006-01-12 at 10:39 -0500, Jeremy Katz wrote: > On Thu, 2006-01-12 at 13:33 +0000, David Woodhouse wrote: > > On Thu, 2006-01-12 at 03:00 -0500, Build System wrote: > > > * Wed Jan 11 2006 Jeremy Katz - 10.91.3-1 > > > - remove some unneeded bits from the ppc boot.iso to make it smaller > > > > Pleased to note that you kept /images/netboot/ppc32.img in it -- we > > actually need that for booting on Pegasos. > > I did actually look to see what the mkisofs invocations used :-P On Pegasos we have to invoke it directly by pathname because the firmware doesn't handle auto-booting of CDs. It's just a coincidence that we happen to use that same image with -prep-boot, and I'm fairly convinced that won't work on PReP anyway. > It doesn't end up helping much. The vast majority of the initrd is the > per-kernel modules. By going with a single initrd, we increase the > memory overhead significantly which I'd rather avoid Ah, ok. Then it wouldn't make much sense, I agree. -- dwmw2 From ivazquez at ivazquez.net Thu Jan 12 15:49:06 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 12 Jan 2006 10:49:06 -0500 Subject: Python namespace in packages In-Reply-To: <1136722311.5036.2.camel@ignacio.lan> References: <1136722311.5036.2.camel@ignacio.lan> Message-ID: <1137080946.26197.3.camel@ignacio.lan> On Sun, 2006-01-08 at 07:11 -0500, Ignacio Vazquez-Abrams wrote: > One thing I've always wondered is why a Python namespace isn't being > used even though it's one of the primary languages used in Fedora. It > doesn't make any sense to me why they aren't implemented. Does anyone > have a reasonable explanation of why not? So does no one else see this as an issue? Or is this the wrong list for such an inquiry? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 nman64 at n-man.com Thu Jan 12 15:50:01 2006 From: nman64 at n-man.com (Patrick Barnes) Date: Thu, 12 Jan 2006 09:50:01 -0600 Subject: Rawhide Reports In-Reply-To: <6280325c0601120622i17692a6xfdda5eb9939426d@mail.gmail.com> References: <6280325c0601110730n782b6e78we2cce58652ee2e64@mail.gmail.com> <43C5BAAC.9090706@n-man.com> <6280325c0601120622i17692a6xfdda5eb9939426d@mail.gmail.com> Message-ID: <43C67AA9.7090003@n-man.com> n0dalus wrote: > On 1/12/06, Patrick Barnes wrote: > > You can try viewing the individual changelogs for the packages using > > ViewCVS. See http://cvs.fedora.redhat.com/ > > Thanks. > I also worked out yesterday I could do `rpm -q --changelog package` -- > I really wish I had known about that before. > > > The new stuff, as seen in the rawhide reports, is always a good place to > > start. You can also follow up on bugs in Bugzilla or on complaints in > > the assorted lists and IRC channels. > > > > I hope that before the test cycle is over there will be a lot more > organization in regard to what needs to be tested. Is it worth making > a wiki page, a #fedora-testing irc channel, etc? > > Thanks, > n0dalus. > > I don't think a new, separate effort really needs to be started. There are some existing projects that such a thing could tie into. You might want to talk to Rahul Sundaram (mether on freenode). He would probably have some pointers to help you out, and he'd probably love any ideas you have about improving testing and QA practices. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From drepper at redhat.com Thu Jan 12 15:55:47 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Thu, 12 Jan 2006 07:55:47 -0800 Subject: Interesting results for getservbyname() performance (and possible changes for /etc/services) In-Reply-To: <20060112153902.GB23571@ryoko.camperquake.de> References: <43C63735.3010609@redhat.com> <1137065761.5864.10.camel@ignacio.lan> <1137071422.9970.43.camel@gibraltar.stuttgart.redhat.com> <20060112132118.GA23571@ryoko.camperquake.de> <1137080215.9970.48.camel@gibraltar.stuttgart.redhat.com> <20060112153902.GB23571@ryoko.camperquake.de> Message-ID: <43C67C03.1090100@redhat.com> Ralf Ertzinger wrote: > AFAIK nscd can cache everything going through nsswitch.conf, including > services. No, you're wrong. nscd only caches passwd, group, hosts data. Nothing else. And I'm reluctant to add support for rarely used other services because the cost doesn't really justify the gains. For this problem, as I told Phil already internally, I think it's perfectly fine to use nss_db. It's really static data so updating the database when a) the /etc/services file changes or b) the nss_db implementation changes, is no big issue. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From icon at fedoraproject.org Thu Jan 12 15:55:24 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 12 Jan 2006 10:55:24 -0500 Subject: Python namespace in packages In-Reply-To: <1137080946.26197.3.camel@ignacio.lan> References: <1136722311.5036.2.camel@ignacio.lan> <1137080946.26197.3.camel@ignacio.lan> Message-ID: <43C67BEC.90601@fedoraproject.org> Ignacio Vazquez-Abrams wrote: > On Sun, 2006-01-08 at 07:11 -0500, Ignacio Vazquez-Abrams wrote: >> One thing I've always wondered is why a Python namespace isn't being >> used even though it's one of the primary languages used in Fedora. It >> doesn't make any sense to me why they aren't implemented. Does anyone >> have a reasonable explanation of why not? > > So does no one else see this as an issue? Or is this the wrong list for > such an inquiry? It's possible that I'm dim, but I have no idea what you're talking about. What is the "python namespace" you mention? Regards, -- Konstantin Ryabitsev McGill University WSG Montr?al, Qu?bec From wtogami at redhat.com Thu Jan 12 15:56:11 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 12 Jan 2006 10:56:11 -0500 Subject: Checksum Failing (Was Re: More mass rebuilds for GCC) In-Reply-To: <20060111212345.GA7106@rednote.net> References: <1134891796.5262.19.camel@ender> <20060109123723.641198d7.fedora@wir-sind-cool.org> <5256d0b0601090338j65ebeee2v1faf2f23ac7c346f@mail.gmail.com> <20060109195009.58f4fb31.fedora@wir-sind-cool.org> <5256d0b0601100759m614c5178se928026f6295fc04@mail.gmail.com> <20060111212345.GA7106@rednote.net> Message-ID: <43C67C1B.3000903@redhat.com> Janina Sajka wrote: > Really delighted to see the new compat-libstdc++ today, but getting the > following attempting to yum them down: > Sorry about the trouble. This error is due to a combination of two factors. We signed the previously unsigned packages, but forgot to repocreate the metadata again. Your yum grabbed the unsigned metadata, which didn't match the checksums on the newly signed packages. Unfortunately everyone that grabbed metadata prior to signing will need to clear their yum cache. Even though today's rawhide is consistent between packages and metadata, everyone will need to use "yum clean headers metadata" in order to proceed with further updates. I consider this to be a bug in yum. Once we accidentally pushed an unsigned package in FC4 Updates. When realizing the problem Sopwith signed and re-pushed it, but anybody who had already downloaded the unsigned header forever was stuck being unable to upgrade. Because we had no choice, we had to rebuild the package so yum would re-grab headers and continue updating stuff without manual intervetion. Warren Togami wtogami at redhat.com From katzj at redhat.com Thu Jan 12 16:00:44 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 12 Jan 2006 11:00:44 -0500 Subject: boot hang with 2.6.15 In-Reply-To: <1137057179.2779.0.camel@xpc.home.erwinrol.com> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <1136899106.3185.5.camel@xpc.home.erwinrol.com> <20060111022103.GJ3704@redhat.com> <1136975340.3455.5.camel@xpc.home.erwinrol.com> <1136976499.2954.0.camel@xpc.home.erwinrol.com> <1136998381.3290.3.camel@xpc.home.erwinrol.com> <20060111203344.GB3688@redhat.com> <1137057179.2779.0.camel@xpc.home.erwinrol.com> Message-ID: <1137081644.9891.6.camel@bree.local.net> On Thu, 2006-01-12 at 10:12 +0100, Erwin Rol wrote: > On Wed, 2006-01-11 at 15:33 -0500, Dave Jones wrote: > > On Wed, Jan 11, 2006 at 05:53:01PM +0100, Erwin Rol wrote: > > ah, x86-64. I'll bet you have an ATI chipset too ? > > I'm chasing that bug right now. I'll bet booting with pci=noacpi makes > > it boot for you (though on the system I'm using to test with, that makes > > it boot, but the network card is useless). > > > > If it's the same bug, rest assured, I'm on it.. > > The new 2.6.15-1.1826.2.10_FC5 kernel works. Great, thanks for the confirmation. Jeremy From ivazquez at ivazquez.net Thu Jan 12 16:16:40 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 12 Jan 2006 11:16:40 -0500 Subject: Python namespace in packages In-Reply-To: <43C67BEC.90601@fedoraproject.org> References: <1136722311.5036.2.camel@ignacio.lan> <1137080946.26197.3.camel@ignacio.lan> <43C67BEC.90601@fedoraproject.org> Message-ID: <1137082600.26197.9.camel@ignacio.lan> On Thu, 2006-01-12 at 10:55 -0500, Konstantin Ryabitsev wrote: > Ignacio Vazquez-Abrams wrote: > > On Sun, 2006-01-08 at 07:11 -0500, Ignacio Vazquez-Abrams wrote: > >> One thing I've always wondered is why a Python namespace isn't being > >> used even though it's one of the primary languages used in Fedora. It > >> doesn't make any sense to me why they aren't implemented. Does anyone > >> have a reasonable explanation of why not? > > > > So does no one else see this as an issue? Or is this the wrong list for > > such an inquiry? > > It's possible that I'm dim, but I have no idea what you're talking > about. What is the "python namespace" you mention? Currently in Perl packages rpmbuild detects what modules are used and provided by the package and creates Requires and Provides tags in the form of "perl(Foo::Bar)". Supposedly there are scripts that can detect module usage in Python apps as well and can generate the appropriate tags, e.g., "Provides: python(kid)". I'm just wondering why Fedora isn't taking advantage of this. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 wtogami at redhat.com Thu Jan 12 16:17:52 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 12 Jan 2006 11:17:52 -0500 Subject: Checksum Failing (Was Re: More mass rebuilds for GCC) In-Reply-To: <43C67C1B.3000903@redhat.com> References: <1134891796.5262.19.camel@ender> <20060109123723.641198d7.fedora@wir-sind-cool.org> <5256d0b0601090338j65ebeee2v1faf2f23ac7c346f@mail.gmail.com> <20060109195009.58f4fb31.fedora@wir-sind-cool.org> <5256d0b0601100759m614c5178se928026f6295fc04@mail.gmail.com> <20060111212345.GA7106@rednote.net> <43C67C1B.3000903@redhat.com> Message-ID: <43C68130.1090408@redhat.com> Warren Togami wrote: > Janina Sajka wrote: >> Really delighted to see the new compat-libstdc++ today, but getting the >> following attempting to yum them down: >> > > Unfortunately everyone that grabbed metadata prior to signing will need > to clear their yum cache. Even though today's rawhide is consistent > between packages and metadata, everyone will need to use "yum clean > headers metadata" in order to proceed with further updates. Ugh... today's rawhide isn't consistent again, because more previously unsigned packages were signed again. Rel-eng is trying to sort this out today. Warren Togami wtogami at redhat.com From icon at fedoraproject.org Thu Jan 12 16:19:02 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 12 Jan 2006 11:19:02 -0500 Subject: Python namespace in packages In-Reply-To: <1137082600.26197.9.camel@ignacio.lan> References: <1136722311.5036.2.camel@ignacio.lan> <1137080946.26197.3.camel@ignacio.lan> <43C67BEC.90601@fedoraproject.org> <1137082600.26197.9.camel@ignacio.lan> Message-ID: <43C68176.1080806@fedoraproject.org> Ignacio Vazquez-Abrams wrote: > Currently in Perl packages rpmbuild detects what modules are used and > provided by the package and creates Requires and Provides tags in the > form of "perl(Foo::Bar)". Supposedly there are scripts that can detect > module usage in Python apps as well and can generate the appropriate > tags, e.g., "Provides: python(kid)". I'm just wondering why Fedora isn't > taking advantage of this. Okay, that's a lot more clear. :) It's a good question, I don't know. I'd be all for introducing this, though. Regards, -- Konstantin Ryabitsev McGill University WSG Montr?al, Qu?bec From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jan 12 16:22:54 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 Jan 2006 17:22:54 +0100 Subject: Checksum Failing (Was Re: More mass rebuilds for GCC) In-Reply-To: <43C68130.1090408@redhat.com> References: <1134891796.5262.19.camel@ender> <20060109123723.641198d7.fedora@wir-sind-cool.org> <5256d0b0601090338j65ebeee2v1faf2f23ac7c346f@mail.gmail.com> <20060109195009.58f4fb31.fedora@wir-sind-cool.org> <5256d0b0601100759m614c5178se928026f6295fc04@mail.gmail.com> <20060111212345.GA7106@rednote.net> <43C67C1B.3000903@redhat.com> <43C68130.1090408@redhat.com> Message-ID: <20060112172254.0dba032d@python2> Warren Togami wrote : > Warren Togami wrote: > > Janina Sajka wrote: > >> Really delighted to see the new compat-libstdc++ today, but getting the > >> following attempting to yum them down: > >> > > > > Unfortunately everyone that grabbed metadata prior to signing will need > > to clear their yum cache. Even though today's rawhide is consistent > > between packages and metadata, everyone will need to use "yum clean > > headers metadata" in order to proceed with further updates. > > Ugh... today's rawhide isn't consistent again, because more previously > unsigned packages were signed again. Rel-eng is trying to sort this out > today. OK, thanks for the info :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.63 0.53 0.47 From michael.favia at insitesinc.com Thu Jan 12 16:26:30 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 12 Jan 2006 10:26:30 -0600 Subject: newly signed packages Message-ID: <43C68336.1060208@insitesinc.com> in spite of the yum metadata issues i would like to thank someone for deciding to start signing these (will it be all?) packages. It really helps guarantee authenticity of the packages and lets me update them with a little more piece of mind. Please keep in mind that signatures only guarantee authenticity and do not certify functionality. i hope that the fedora testing community understands these difference because that was the reason given for not signing the packages when i asked last year. -mf From mitr at volny.cz Thu Jan 12 16:30:40 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Thu, 12 Jan 2006 17:30:40 +0100 Subject: newly signed packages In-Reply-To: <43C68336.1060208@insitesinc.com> References: <43C68336.1060208@insitesinc.com> Message-ID: <43C68430.1080208@volny.cz> Michael Favia wrote: > in spite of the yum metadata issues i would like to thank someone for > deciding to start signing these (will it be all?) packages. The packages are signed for the test release, I don't think rawhide will stay signed from now on. Mirek From katzj at redhat.com Thu Jan 12 16:34:39 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 12 Jan 2006 11:34:39 -0500 Subject: Python namespace in packages In-Reply-To: <1137080946.26197.3.camel@ignacio.lan> References: <1136722311.5036.2.camel@ignacio.lan> <1137080946.26197.3.camel@ignacio.lan> Message-ID: <1137083679.9891.9.camel@bree.local.net> On Thu, 2006-01-12 at 10:49 -0500, Ignacio Vazquez-Abrams wrote: > On Sun, 2006-01-08 at 07:11 -0500, Ignacio Vazquez-Abrams wrote: > > One thing I've always wondered is why a Python namespace isn't being > > used even though it's one of the primary languages used in Fedora. It > > doesn't make any sense to me why they aren't implemented. Does anyone > > have a reasonable explanation of why not? > > So does no one else see this as an issue? Or is this the wrong list for > such an inquiry? It's mostly a matter of 'round 'tuits. :-/ We should definitely try to make sure it gets done for FC6, though. If someone wants to go ahead and get the necessary changes lined up, that would make it a bit easier to do as well Jeremy From pmatilai at laiskiainen.org Thu Jan 12 16:39:34 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 12 Jan 2006 18:39:34 +0200 Subject: Compilation problem with gcc 4.1, c++ include files In-Reply-To: <20060112134508.67d3f07b@python2> References: <20060112130334.6474fa2d@python2> <20060112120839.GT7768@devserv.devel.redhat.com> <20060112134508.67d3f07b@python2> Message-ID: <1137083974.2869.9.camel@weasel.turre.laiskiainen.org> On Thu, 2006-01-12 at 13:45 +0100, Matthias Saou wrote: > Jakub Jelinek wrote : > > If you are compiling 64-bit stuff, you of course need > > libstdc++-devel-4.1.0-*.x86_64.rpm installed. From your description > > it sounds like only libstdc++-devel-4.1.0-*.i386.rpm is installed. > > That's it! > Now... try to figure out why mach/yum installed *only* the i386 version in > the x86_64 root... > > $ mach -r fedora-development-x86_64-extras yum list libstdc++-devel > Setting up Repos > core 100% |=========================| 951 B 00:00 > extras 100% |=========================| 1.1 kB 00:00 > local 100% |=========================| 951 B 00:00 > Reading repository metadata in from local files > core : ################################################## 3601/3601 > extras : ################################################## 2994/2994 > local : ################################################## 8/8 > Installed Packages > libstdc++-devel.i386 4.1.0-0.14 installed > Available Packages > libstdc++-devel.x86_64 4.1.0-0.14 core It'll install x86_64 version on the next run :) See https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00479.html - Panu - From michael.favia at insitesinc.com Thu Jan 12 16:42:44 2006 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 12 Jan 2006 10:42:44 -0600 Subject: newly signed packages In-Reply-To: <43C68430.1080208@volny.cz> References: <43C68336.1060208@insitesinc.com> <43C68430.1080208@volny.cz> Message-ID: <43C68704.40801@insitesinc.com> Miloslav Trmac wrote: > Michael Favia wrote: >> in spite of the yum metadata issues i would like to thank someone for >> deciding to start signing these (will it be all?) packages. > The packages are signed for the test release, I don't think rawhide will > stay signed from now on. Is there any good reason not to sign them? -mf From ph18 at cornell.edu Thu Jan 12 16:52:53 2006 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 12 Jan 2006 11:52:53 -0500 Subject: Interesting results for getservbyname() performance (and possible changes for /etc/services) In-Reply-To: <1137080215.9970.48.camel@gibraltar.stuttgart.redhat.com> References: <43C63735.3010609@redhat.com> <1137065761.5864.10.camel@ignacio.lan> <1137071422.9970.43.camel@gibraltar.stuttgart.redhat.com> <20060112132118.GA23571@ryoko.camperquake.de> <1137080215.9970.48.camel@gibraltar.stuttgart.redhat.com> Message-ID: <43C68965.2020705@cornell.edu> Nils Philippsen wrote: > > nscd can't (or at least doesn't) take advantage of knowing about local > file changes, it caches information for a certain time period and it > doesn't seem to cache services, only passwd, group, hosts. > > How often do you update /etc/services? You can always clear the cache by kicking ncsd. If you're updating /etc/services via an rpm, you can kick ncsd in the postinstall script. From pknirsch at redhat.com Thu Jan 12 16:56:10 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Thu, 12 Jan 2006 17:56:10 +0100 Subject: Interesting results for getservbyname() performance (and possible changes for /etc/services) In-Reply-To: <43C67C03.1090100@redhat.com> References: <43C63735.3010609@redhat.com> <1137065761.5864.10.camel@ignacio.lan> <1137071422.9970.43.camel@gibraltar.stuttgart.redhat.com> <20060112132118.GA23571@ryoko.camperquake.de> <1137080215.9970.48.camel@gibraltar.stuttgart.redhat.com> <20060112153902.GB23571@ryoko.camperquake.de> <43C67C03.1090100@redhat.com> Message-ID: <43C68A2A.5020709@redhat.com> Ulrich Drepper wrote: > Ralf Ertzinger wrote: > >>AFAIK nscd can cache everything going through nsswitch.conf, including >>services. > > > No, you're wrong. nscd only caches passwd, group, hosts data. Nothing > else. > > And I'm reluctant to add support for rarely used other services because > the cost doesn't really justify the gains. For this problem, as I told > Phil already internally, I think it's perfectly fine to use nss_db. > It's really static data so updating the database when a) the > /etc/services file changes or b) the nss_db implementation changes, is > no big issue. > > I've quickly ran some tests with this change. Here the results: Unkown service "foobar": old: 7.65user 5.51system 2:06.60elapsed new: 63.99user 10.55system 3:09.55elapsed old.db: 9.38user 14.36system 2:17.05elapsed new.db: 66.80user 19.56system 3:22.44elapsed Known service "svn" (roughly in the middle of both files): old: 1.92user 0.42system 0:02.35elapsed new: 39.91user 3.52system 0:43.43elapsed old.db: 0.60user 8.30system 0:08.91elapsed new.db: 0.72user 8.48system 0:09.21elapsed Known service "ssh" (very early in both files): old: 0.20user 0.27system 0:00.47elapsed new: 0.26user 0.28system 0:00.55elapsed old.db: 0.68user 8.53system 0:09.22elapsed new.db: 0.62user 8.41system 0:09.04elapsed The result here is fairly interesting again. For small /etc/services files or if almost always only the first 40-50 services are requested the non-db version wins always. The bigger the file gets though and the more "later" services are requested the faster the db version gets (fairly logical of course). So the use of the db version depends on wether your applications use a wide range of services and if your /etc/services file is big. As almost always, there is no perfect solution for everyone. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Kaa's Law: In any sufficiently large group of people most are idiots. From lamont at gurulabs.com Thu Jan 12 16:59:30 2006 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 12 Jan 2006 09:59:30 -0700 Subject: Interesting results for getservbyname() performance ( and possible changes for /etc/services) In-Reply-To: <43C68965.2020705@cornell.edu> References: <43C63735.3010609@redhat.com> <1137080215.9970.48.camel@gibraltar.stuttgart.redhat.com> <43C68965.2020705@cornell.edu> Message-ID: <200601120959.34638.lamont@gurulabs.com> On Thursday 12 January 2006 09:52am, Paul A Houle wrote: > Nils Philippsen wrote: > > nscd can't (or at least doesn't) take advantage of knowing about local > > file changes, it caches information for a certain time period and it > > doesn't seem to cache services, only passwd, group, hosts. > > How often do you update /etc/services? > > You can always clear the cache by kicking ncsd. If you're updating > /etc/services via an rpm, you can kick ncsd in the postinstall script. Actually, I found out differently just yesterday. I was working on an issue caused by SELinux policy relating to nscd when using TLS encrypted LDAP for authentication & user information. During my testing, I had to stop nscd and "rm /var/db/nscd/*" (which only has group, hosts & passwd) and then restart nscd, in order to clear the cache. Is there some mystery switch to do this that I'm missing? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From eharrison at mail.mesd.k12.or.us Thu Jan 12 17:29:12 2006 From: eharrison at mail.mesd.k12.or.us (Eric Harrison) Date: Thu, 12 Jan 2006 09:29:12 -0800 Subject: Interesting results for getservbyname() performance ( and possible changes for /etc/services) In-Reply-To: <200601120959.34638.lamont@gurulabs.com> References: <43C63735.3010609@redhat.com> <1137080215.9970.48.camel@gibraltar.stuttgart.redhat.com> <43C68965.2020705@cornell.edu> <200601120959.34638.lamont@gurulabs.com> Message-ID: <43C691E8.7060403@mail.mesd.k12.or.us> Lamont R. Peterson wrote: > On Thursday 12 January 2006 09:52am, Paul A Houle wrote: > >>Nils Philippsen wrote: >> >>>nscd can't (or at least doesn't) take advantage of knowing about local >>>file changes, it caches information for a certain time period and it >>>doesn't seem to cache services, only passwd, group, hosts. >> >> How often do you update /etc/services? >> >> You can always clear the cache by kicking ncsd. If you're updating >>/etc/services via an rpm, you can kick ncsd in the postinstall script. > > > Actually, I found out differently just yesterday. > > I was working on an issue caused by SELinux policy relating to nscd when using > TLS encrypted LDAP for authentication & user information. During my testing, > I had to stop nscd and "rm /var/db/nscd/*" (which only has group, hosts & > passwd) and then restart nscd, in order to clear the cache. > > Is there some mystery switch to do this that I'm missing? > mystery switch = -i nscd -i passwd nscd -i group nscd -i hosts # nscd --help Usage: nscd [OPTION...] Name Service Cache Daemon. -d, --debug Do not fork and display messages on the current tty -f, --config-file=NAME Read configuration data from NAME -g, --statistic Print current configuration statistic -i, --invalidate=TABLE Invalidate the specified cache -K, --shutdown Shut the server down -t, --nthreads=NUMBER Start NUMBER threads -?, --help Give this help list --usage Give a short usage message -V, --version Print program version -Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From kloczek at zie.pg.gda.pl Thu Jan 12 17:38:38 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Thu, 12 Jan 2006 18:38:38 +0100 Subject: broken master yum repository Message-ID: <1137087518.3615.20.camel@test1.zie.pg.gda.pl> http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/lcms-1.15-1.i386.rpm: [Errno -1] Package does not match checksum http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/libwmf-0.2.8.4-3.i386.rpm: [Errno -1] Package does not match checksum kloczek From dgregor at redhat.com Thu Jan 12 17:43:12 2006 From: dgregor at redhat.com (Dennis Gregorovic) Date: Thu, 12 Jan 2006 12:43:12 -0500 Subject: broken master yum repository In-Reply-To: <1137087518.3615.20.camel@test1.zie.pg.gda.pl> References: <1137087518.3615.20.camel@test1.zie.pg.gda.pl> Message-ID: <1137087792.25916.8.camel@localhost.localdomain> On Thu, 2006-01-12 at 18:38 +0100, Tomasz K?oczko wrote: > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/lcms-1.15-1.i386.rpm: [Errno -1] Package does not match checksum > http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/libwmf-0.2.8.4-3.i386.rpm: [Errno -1] Package does not match checksum > > kloczek I just finished a push of new repodata that should fix this problem. Cheers -- Dennis From jspaleta at gmail.com Wed Jan 11 15:16:51 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 11 Jan 2006 10:16:51 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> Message-ID: <604aa7910601110716g64f61badv996bbe0140de0222@mail.gmail.com> On 1/11/06, Nicolas Mailhot wrote: > gthumb can be used for casual browsing/manipulation of any directory > containing image files Aren't there other ways already in Core to casually browse directories of images? Doesn't nautilus provide some functionality for casual viewing of images via eog? > f-spot can not - in insists in importing/pre-processing ever picture > directory before making it available. So it's more a centralised picture > management app And i think a default application that is more centralized and more focused is very much consistent with previous fedora core functionality decisions. f-spot is to photos as rhythmbox is to music > Till f-spot gets a "casual browsing mode" it's not a real gthumb replacement The question as to Core/Extras is never about feature-for-feature replacements. It's never about most features either. The question is prioritization of functionality. You can not deny that there is significant overlap here between these applications and general function. The question becomes what is the primary functionality that Fedora Core is attempting to fill and how well does each candidate application fill that role. As to the question of which functionality is more important.. casual browsing or centralized management. I'm not really sure casual browsing of images outside of the filemanager is that important compared to centralized photo management at this point. I do however feel strongly that a choice needs to be made and one of these applications should be in Core, and the other should move to Extras. eog,gthumb,f-spot i do not think all 3 should be in Core. -jef From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jan 12 18:41:04 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 12 Jan 2006 19:41:04 +0100 Subject: Apache mod_mono? Message-ID: <20060112194104.1c7154d7@python2> Hi, It seems like an incredible coincidence, but someone I know who works with Windows/IIS just told me that he wanted to rewrite an old website he has in ASP.NET... just when mono went into Fedora Core! So I was looking around, and came across the mono ASP.NET page : http://www.mono-project.com/ASP.NET Seems like it's already pretty mature, so I'd really like to give a shot at convincing him of using Fedora/Apache/Mono. Are there any plans on getting mod_mono into Core? If not, is anyone thinking about getting it into Extras? If still not, I think I might give it a shot ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1656_FC4 Load : 0.43 0.42 0.54 From seg at haxxed.com Thu Jan 12 18:58:49 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 12 Jan 2006 12:58:49 -0600 Subject: Interesting results for getservbyname() performance (and possible changes for /etc/services) In-Reply-To: <43C68A2A.5020709@redhat.com> References: <43C63735.3010609@redhat.com> <1137065761.5864.10.camel@ignacio.lan> <1137071422.9970.43.camel@gibraltar.stuttgart.redhat.com> <20060112132118.GA23571@ryoko.camperquake.de> <1137080215.9970.48.camel@gibraltar.stuttgart.redhat.com> <20060112153902.GB23571@ryoko.camperquake.de> <43C67C03.1090100@redhat.com> <43C68A2A.5020709@redhat.com> Message-ID: <1137092329.4507.11.camel@localhost.localdomain> Err, how often are service lookups done? How performance critical is this, really? Seems to me an application doing a large number of lookups is best off just slurping in /etc/services itself (Or just keep its own service list) and building its own hash table in RAM or whatnot. (Which IIRC is what stuff like nmap and ethereal do...) Benchmark a real application first, then optimize. ;P -------------- 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 seg at haxxed.com Thu Jan 12 19:26:23 2006 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 12 Jan 2006 13:26:23 -0600 Subject: bash 3.1 gotcha Message-ID: <1137093984.4507.26.camel@localhost.localdomain> For many years, I have had a fancy bash prompt, that contains this: ${PWD/#$HOME/~} This replaces your home dir with a tilde. However, with bash 3.1, it stopped working: seg at bigtime:/home/seg $ rpm -q bash bash-3.1-2 seg at bigtime:/home/seg $ echo ${PWD/#$HOME/~} /home/seg It works in bash 3.0 and earlier: seg at hamburger:~ $ rpm -q bash bash-3.0-31 seg at hamburger:~ $ echo ${PWD/#$HOME/~} ~ I was very confused, until I figured out the ~ was now getting expanded to $HOME, thus $HOME was getting replaced with $HOME! So escaping the tilde fixes it: seg at bigtime:~ $ echo ${PWD/#$HOME/\~} ~ I don't know if this is a bug or not. And may be too obscure for anyone to care, but there it is. -------------- 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 cmadams at hiwaay.net Thu Jan 12 19:31:55 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 12 Jan 2006 13:31:55 -0600 Subject: bash 3.1 gotcha In-Reply-To: <1137093984.4507.26.camel@localhost.localdomain> References: <1137093984.4507.26.camel@localhost.localdomain> Message-ID: <20060112193155.GF1547370@hiwaay.net> Once upon a time, Callum Lerwick said: > For many years, I have had a fancy bash prompt, that contains this: > ${PWD/#$HOME/~} This replaces your home dir with a tilde. However, with > bash 3.1, it stopped working: Why not just use the bash PS1 "\w" escape which does the same thing? Much easier and won't break (unless there's a bug). See the PROMPTING secion of the bash man page. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From gianluca.cecchi at gmail.com Thu Jan 12 20:43:01 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 12 Jan 2006 21:43:01 +0100 Subject: automount of secondary hard disks / partitions: new? Message-ID: <561c252c0601121243l61eea568u@mail.gmail.com> Hello, I have fc5 devel root on /dev/sdb2 and I noticed that it automatically mounted my first disk's partitions, and my other /dev/sdb1 partition, also creating mount points, with the names below... I'm sure few days ago the behaviour was not this [gcecchi at fedora ~]$ df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb2 11337596 8464660 2297008 79% / /dev/shm 515672 0 515672 0% /dev/shm /dev/sda1 101086 32525 63342 34% /media/disk /dev/sda3 49224744 43782308 4442232 91% /media/disk-1 /dev/sda5 68326840 61769756 5168748 93% /media/disk-2 /dev/sdb1 3142552 2841328 301224 91% /media/disk-3 Where do I find config choices/settings for this? Such as mount-path, rw/ro mounting, ecc? I searched in autofs and udev but I seems not to find anything useful? Thanks Gianluca From katzj at redhat.com Thu Jan 12 20:54:17 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 12 Jan 2006 15:54:17 -0500 Subject: automount of secondary hard disks / partitions: new? In-Reply-To: <561c252c0601121243l61eea568u@mail.gmail.com> References: <561c252c0601121243l61eea568u@mail.gmail.com> Message-ID: <1137099258.2854.9.camel@bree.local.net> On Thu, 2006-01-12 at 21:43 +0100, Gianluca Cecchi wrote: > I have fc5 devel root on /dev/sdb2 and I noticed that it automatically mounted > my first disk's partitions, and my other /dev/sdb1 partition, also > creating mount points, > with the names below... [snip] > Where do I find config choices/settings for this? Such as mount-path, > rw/ro mounting, ecc? > I searched in autofs and udev but I seems not to find anything useful? This is related to the changes in hal and gnome-mount of late, although I'm not 100% sure where the exact pieces are at this point Jeremy From gianluca.cecchi at gmail.com Thu Jan 12 21:21:08 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 12 Jan 2006 22:21:08 +0100 Subject: totem great instability Message-ID: <561c252c0601121321n583aedfbt@mail.gmail.com> Not considering the fact that you are able to play near nothing with it, this piece of software is very unstable. Previous versions quite often crashed at launch or after selecting some menu items The latest totem-1.3.0-3, while navigating through file system, often freezes and doing strace of pid gives continuously something like what below. Does it make sens to include totem in core, when every one that wants to see videos in fedora, removes totem and installs then totem-xine (plus decoding/navigating libraries) or other similar applications like mplayer or vlc? Gianluca [gcecchi at fedora fedora]$ strace -p 1665 Process 1665 attached - interrupt to quit poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 semop(0, 0xbfcf4720, 2) = 0 shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 semop(0, 0xbfcf472c, 1) = 0 poll( From johnp at redhat.com Thu Jan 12 22:04:26 2006 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 12 Jan 2006 17:04:26 -0500 Subject: totem great instability In-Reply-To: <561c252c0601121321n583aedfbt@mail.gmail.com> References: <561c252c0601121321n583aedfbt@mail.gmail.com> Message-ID: <1137103466.2774.65.camel@remedyz.boston.redhat.com> Totem/gstreamer is the way to go especially if you want to be able to install proprietary codecs from a licensed source in the future. Please file a bug if you find problems. Upstream is the best place where it will get fixed the fastest. On Thu, 2006-01-12 at 22:21 +0100, Gianluca Cecchi wrote: > Not considering the fact that you are able to play near nothing with > it, this piece of software > is very unstable. > Previous versions quite often crashed at launch or after selecting > some menu items > The latest totem-1.3.0-3, while navigating through file system, often > freezes and > doing strace of pid gives continuously something like what below. > Does it make sens to include totem in core, when every one that wants to see > videos in fedora, removes totem and installs then totem-xine (plus > decoding/navigating > libraries) or other similar applications like mplayer or vlc? > Gianluca > > > [gcecchi at fedora fedora]$ strace -p 1665 > Process 1665 attached - interrupt to quit > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll([{fd=28, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0 > semop(0, 0xbfcf4720, 2) = 0 > shmctl(1933313, IPC_64|IPC_STAT, 0xbfcf46cc) = 0 > semop(0, 0xbfcf472c, 1) = 0 > poll( > -- From gianluca.cecchi at gmail.com Thu Jan 12 22:05:40 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 12 Jan 2006 23:05:40 +0100 Subject: automount of secondary hard disks / partitions: new? Message-ID: <561c252c0601121405r76c3dbfs@mail.gmail.com> Jeremy Katz wrote: >This is related to the changes in hal and gnome-mount of late, although >I'm not 100% sure where the exact pieces are at this point Infact when in init 3 or init 5 without logging in, the /media/xxxxx mounts are not present. I will dag... From gianluca.cecchi at gmail.com Thu Jan 12 22:11:43 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 12 Jan 2006 23:11:43 +0100 Subject: ugly cursor? How did the story end? Message-ID: <561c252c0601121411n319f21a5l@mail.gmail.com> Hello, from system---> preferences ---> mouse ---> cursor tab, there are no themes installable And the default I have is ugly (old days clock and old-old days white hand): so these will be the default and only usable mouse-themes? Thaks in advance Gianluca From jspaleta at gmail.com Thu Jan 12 11:08:44 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 12 Jan 2006 06:08:44 -0500 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <43C55FA6.7010109@cornell.edu> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> <43C5217D.3010408@redhat.com> <13538.192.54.193.25.1136998392.squirrel@rousalka.dyndns.org> <43C538DD.3090209@redhat.com> <10427.192.54.193.25.1137001819.squirrel@rousalka.dyndns.org> <43C54815.1020302@redhat.com> <43C55FA6.7010109@cornell.edu> Message-ID: <604aa7910601120308q13617063h515f311aea06db8e@mail.gmail.com> On 1/11/06, Paul A Houle wrote: > I've been screwing around a bit with scripts that try to audit what > rpms a particular system is using. I've tried two different approaches: [snip] Instead of trying to capture it all. Would be interesting enough to just try to capture items which are started from the desktop menu structure or started via interaction with the file browser or via the desktop session on login. Focus on "classical" desktop usage and just ignore all the other random bits started via a terminal or by background processes. Could hooks be put into gnome-session and whatever controls desktop startup notification that the window list applet uses to tell me that evo is starting before the evo window appears? Then you could get some counts as to what applications/applets users are starting up via UI interaction. -jef From dwmw2 at infradead.org Thu Jan 12 23:12:46 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 12 Jan 2006 23:12:46 +0000 Subject: rawhide report: 20060110 changes [extras packages moved to core] In-Reply-To: <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> References: <200601100929.k0A9T5CM017018@porkchop.devel.redhat.com> <200601100357.21617.dennis@ausil.us> <1136888676.8026.48.camel@greebo> <33538.129.42.161.36.1136918191.squirrel@jdub.homelinux.org> <604aa7910601101044i2e43d148q99292cd345da13b6@mail.gmail.com> <25741.192.54.193.25.1136977481.squirrel@rousalka.dyndns.org> Message-ID: <1137107566.3085.14.camel@localhost.localdomain> On Wed, 2006-01-11 at 12:04 +0100, Nicolas Mailhot wrote: > f-spot can not - in insists in importing/pre-processing ever picture > directory before making it available. So it's more a centralised > picture management app > > Till f-spot gets a "casual browsing mode" it's not a real gthumb > replacement Nah. It's GNOME -- they'll just tell you that you're abnormal if you want to do that. That's not what the theoretical 'idiot user' does. -- dwmw2 From ivazquez at ivazquez.net Fri Jan 13 00:03:22 2006 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 12 Jan 2006 19:03:22 -0500 Subject: ugly cursor? How did the story end? In-Reply-To: <561c252c0601121411n319f21a5l@mail.gmail.com> References: <561c252c0601121411n319f21a5l@mail.gmail.com> Message-ID: <1137110602.3789.2.camel@ignacio.lan> On Thu, 2006-01-12 at 23:11 +0100, Gianluca Cecchi wrote: > from system---> preferences ---> mouse ---> cursor tab, there are no > themes installable > And the default I have is ugly (old days clock and old-old days white hand): > so these will be the default and only usable mouse-themes? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176004 -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 mpeters at mac.com Fri Jan 13 03:40:02 2006 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 12 Jan 2006 19:40:02 -0800 Subject: totem great instability In-Reply-To: <561c252c0601121321n583aedfbt@mail.gmail.com> References: <561c252c0601121321n583aedfbt@mail.gmail.com> Message-ID: <1137123602.21856.5.camel@locolhost.localdomain> On Thu, 2006-01-12 at 22:21 +0100, Gianluca Cecchi wrote: > Not considering the fact that you are able to play near nothing with > it, this piece of software > is very unstable. With the gstreamer plugins from rpm.l*vna.org - it plays quite a few codecs for me. Rarely do I need to fireup mplayer. > Previous versions quite often crashed at launch or after selecting > some menu items > The latest totem-1.3.0-3, while navigating through file system, often > freezes and > doing strace of pid gives continuously something like what below. I can't speak to that. Totem in fc4 works fairly well for me, I have not tried the devel branch - but keep in mind that a new gstreamer was just released, so there may be some quirks from that. > Does it make sens to include totem in core, when every one that wants to see > videos in fedora, removes totem and installs then totem-xine (plus > decoding/navigating > libraries) or other similar applications like mplayer or vlc? Yes it makes sense. As has been mentioned - plugins. Currently most of the cool plugins have the same patent distribution problems as xine/mplayer, but hopefully fluendo (and others?) will fill that gap nicely. From sundaram at redhat.com Fri Jan 13 06:03:10 2006 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 13 Jan 2006 11:33:10 +0530 Subject: Rawhide Reports In-Reply-To: <6280325c0601120622i17692a6xfdda5eb9939426d@mail.gmail.com> References: <6280325c0601110730n782b6e78we2cce58652ee2e64@mail.gmail.com> <43C5BAAC.9090706@n-man.com> <6280325c0601120622i17692a6xfdda5eb9939426d@mail.gmail.com> Message-ID: <43C7429E.9010308@redhat.com> Hi >I hope that before the test cycle is over there will be a lot more >organization in regard to what needs to be tested. Is it worth making >a wiki page, a #fedora-testing irc channel, etc? > > There is already #fedora-bugs. Talk to me if you want to contribute. -- Rahul Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers From naoki at valuecommerce.com Fri Jan 13 07:15:16 2006 From: naoki at valuecommerce.com (Naoki) Date: Fri, 13 Jan 2006 16:15:16 +0900 Subject: Gaim 2 ? Message-ID: <1137136516.21064.239.camel@dragon.sys.intra> Just wondering with the release of gaim 2.0.0 beta1 does anybody think 2.0.0 will make it into FC5? I'm guessing with test2 frozen probably not but thought I would ask anyway. -------------- next part -------------- An HTML attachment was scrubbed... URL: From radekvokal at gmail.com Fri Jan 13 07:27:02 2006 From: radekvokal at gmail.com (Radek =?ISO-8859-1?Q?Vok=E1l?=) Date: Fri, 13 Jan 2006 08:27:02 +0100 Subject: Gaim 2 ? In-Reply-To: <1137136516.21064.239.camel@dragon.sys.intra> References: <1137136516.21064.239.camel@dragon.sys.intra> Message-ID: <1137137222.18247.15.camel@localhost.localdomain> On Fri, 2006-01-13 at 16:15 +0900, Naoki wrote: > Just wondering with the release of gaim 2.0.0 beta1 does anybody think > 2.0.0 will make it into FC5? > > I'm guessing with test2 frozen probably not but thought I would ask > anyway. I hope it won't, it's really too buggy right now (and that's why it's beta1) -- Radek Vok?l From kevinverma at gmail.com Fri Jan 13 07:12:17 2006 From: kevinverma at gmail.com (Kevin Verma) Date: Fri, 13 Jan 2006 12:42:17 +0530 Subject: testing PCMCIA setup under FC5, for Sierra Aircard555 CMDA modem (url's updated) In-Reply-To: References: <20060108220410.GA29800@dominikbrodowski.de> Message-ID: Dear Dominik, I had patched as follwing in serial_cs.c : PCMCIA_DEVICE_CIS_MANF_CARD(0x0192, 0xa555, "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem -- pr e update */ PCMCIA_DEVICE_CIS_MANF_CARD(0x013f, 0xa555, "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem -- po st update */ The result now is that I see the pcccard info as below: PRODID_1="Sierra Wireless" PRODID_2="AirCard 555" PRODID_3="A555" PRODID_4="Rev 1" MANFID=0192,a555 FUNCID=6 This however does not help, and I then have to try executing pcmcia-socket-startup , that wont help too. So the only help finally to have this modem accessible is the following command sequence: cat /lib/firmware/SW_555_SER.cis > /sys/class/pcmcia_socket/pcmcia_socket0/cis /sbin/pcmcia-socket-startup I'll be very much thankful for any further followup to have this solved for a true PnP setup. Many Thanks, Kevin On 1/10/06, Kevin Verma wrote: > Thanks very much for your input, I shall respond soon as it is tested out, > > Cheers, > > On 1/9/06, Dominik Brodowski wrote: > > Hi, > > > > On Mon, Dec 26, 2005 at 01:08:27PM +0530, Kevin Verma wrote: > > > After patching (as on blog_url above) the serial_cs.c, I noticed > > > that this PCMCIA device reports different manufacture_id on FC4 > > > and FC5, further I noticed the same is happening on FC5 box > > > before and after manual firmware loading as below in command > > > line snippet. > > > > > > Before you look into the snippet below I will also like to point > > > out that confused about different manufacture_id reporting I > > > re-patched the serial_cs.c and below is what is being used for > > > the snippet bellow, here: > > > +PCMCIA_DEVICE_CIS_MANF_CARD(0x013f, 0xa555, > > > "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem */ > > > > Oh, they change the MANF_ID in the CIS "firmware" "update"... This is why we > > need two lines in serial_cs to handle it: > > > > diff --git a/drivers/serial/serial_cs.c b/drivers/serial/serial_cs.c > > index 96969cb..c303336 100644 > > --- a/drivers/serial/serial_cs.c > > +++ b/drivers/serial/serial_cs.c > > @@ -785,6 +785,8 @@ static struct pcmcia_device_id serial_id > > PCMCIA_MFC_DEVICE_CIS_MANF_CARD(1, 0x0101, 0x0035, "3CXEM556.cis"), > > PCMCIA_MFC_DEVICE_CIS_MANF_CARD(1, 0x0101, 0x003d, "3CXEM556.cis"), > > PCMCIA_DEVICE_CIS_MANF_CARD(0x0192, 0x0710, "SW_7xx_SER.cis"), /* Sierra Wireless AC710/AC750 GPRS Network Adapter R1 */ > > + PCMCIA_DEVICE_CIS_MANF_CARD(0x0192, 0xa555, "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem -- pre update */ > > + PCMCIA_DEVICE_CIS_MANF_CARD(0x013f, 0xa555, "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem -- post update */ > > PCMCIA_DEVICE_CIS_PROD_ID12("MultiTech", "PCMCIA 56K DataFax", 0x842047ee, 0xc2efcf03, "MT5634ZLX.cis"), > > PCMCIA_DEVICE_CIS_PROD_ID12("ADVANTECH", "COMpad-32/85B-4", 0x96913a85, 0xcec8f102, "COMpad4.cis"), > > PCMCIA_DEVICE_CIS_PROD_ID123("ADVANTECH", "COMpad-32/85", "1.0", 0x96913a85, 0x8fbe92ae, 0x0877b627, "COMpad2.cis"), > > > > > > > > > > Could you test this patch, please? -- whether the CIS update is loaded > > automagically then and whether it works "out of the box" then? > > > > Thanks! > > > > Dominik > > > From buildsys at redhat.com Fri Jan 13 08:23:04 2006 From: buildsys at redhat.com (Build System) Date: Fri, 13 Jan 2006 03:23:04 -0500 Subject: rawhide report: 20060113 changes Message-ID: <200601130823.k0D8N4HZ026774@porkchop.devel.redhat.com> Updated Packages: (none) Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) From nicolas.mailhot at laposte.net Fri Jan 13 08:42:20 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 13 Jan 2006 09:42:20 +0100 (CET) Subject: totem great instability In-Reply-To: <1137123602.21856.5.camel@locolhost.localdomain> References: <561c252c0601121321n583aedfbt@mail.gmail.com> <1137123602.21856.5.camel@locolhost.localdomain> Message-ID: <57439.192.54.193.34.1137141740.squirrel@rousalka.dyndns.org> On Ven 13 janvier 2006 04:40, Michael A. Peters wrote: > I can't speak to that. > Totem in fc4 works fairly well for me, I have not tried the devel branch > - but keep in mind that a new gstreamer was just released, so there may > be some quirks from that. FC4 totem is fine Rawhide totem + gstreamer is way unstable right now -- Nicolas Mailhot From seg at haxxed.com Fri Jan 13 09:13:54 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 13 Jan 2006 03:13:54 -0600 Subject: bash 3.1 gotcha In-Reply-To: <20060112193155.GF1547370@hiwaay.net> References: <1137093984.4507.26.camel@localhost.localdomain> <20060112193155.GF1547370@hiwaay.net> Message-ID: <1137143634.3902.1.camel@localhost.localdomain> On Thu, 2006-01-12 at 13:31 -0600, Chris Adams wrote: > Why not just use the bash PS1 "\w" escape which does the same thing? > Much easier and won't break (unless there's a bug). See the PROMPTING > secion of the bash man page. Because its not in PS1. Full script here: http://www.haxxed.com/random/bash-prompt -------------- 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 seg at haxxed.com Fri Jan 13 09:21:06 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 13 Jan 2006 03:21:06 -0600 Subject: bash 3.1 gotcha In-Reply-To: <1137143634.3902.1.camel@localhost.localdomain> References: <1137093984.4507.26.camel@localhost.localdomain> <20060112193155.GF1547370@hiwaay.net> <1137143634.3902.1.camel@localhost.localdomain> Message-ID: <1137144066.3902.5.camel@localhost.localdomain> On Fri, 2006-01-13 at 03:13 -0600, Callum Lerwick wrote: > Because its not in PS1. Full script here: Or wait, maybe it is. But its doing some fancy mangling to keep it all on one line... -------------- 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 pknirsch at redhat.com Fri Jan 13 09:21:48 2006 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 13 Jan 2006 10:21:48 +0100 Subject: Interesting results for getservbyname() performance (and possible changes for /etc/services) In-Reply-To: <1137092329.4507.11.camel@localhost.localdomain> References: <43C63735.3010609@redhat.com> <1137065761.5864.10.camel@ignacio.lan> <1137071422.9970.43.camel@gibraltar.stuttgart.redhat.com> <20060112132118.GA23571@ryoko.camperquake.de> <1137080215.9970.48.camel@gibraltar.stuttgart.redhat.com> <20060112153902.GB23571@ryoko.camperquake.de> <43C67C03.1090100@redhat.com> <43C68A2A.5020709@redhat.com> <1137092329.4507.11.camel@localhost.localdomain> Message-ID: <43C7712C.40101@redhat.com> Callum Lerwick wrote: > Err, how often are service lookups done? How performance critical is > this, really? Seems to me an application doing a large number of lookups > is best off just slurping in /etc/services itself (Or just keep its own > service list) and building its own hash table in RAM or whatnot. (Which > IIRC is what stuff like nmap and ethereal do...) > > Benchmark a real application first, then optimize. ;P > Well, if you would have read my original post you'd have found the following paragraph in it: Another thing that might be worth looking into is to run some analysis what services are most often requested on standard everyday machines and maybe move them more to the front so they get read and parsed earlier. :P And doing those first few checks i did was important as with that information i can now optimize the common case a lot better as soon as i have run some real life tests on some workstations and servers here. And i can do that optimization application independent. If some application needs/wants to work with large portions of /etc/services repeatedly of course it needs to be optimized, but that won't help the hundreds of other applications, maybe even closed source ones. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From chabotc at xs4all.nl Fri Jan 13 16:14:57 2006 From: chabotc at xs4all.nl (Chris Chabot) Date: Fri, 13 Jan 2006 17:14:57 +0100 Subject: Weird totem/gstreamer crash caused by missing alsa config files? Message-ID: <1137168897.1951.8.camel@localhost.localdomain> Hey all, On my box here totem would crash the moment it started up every time with the error: An error occured Could not open resource for writing Kind of cryptic and completely lacking of any helpfull meaning of what resource it is trying to open for writing, so after discounting other options (gstreamer dependencies, etc) i fired up strace and tried to find what file opens failed. After wading thru tons of strace info using: # strace -e trace=file /usr/bin/totem I noticed that the final file opens that failed before giving that error were for: /etc/alsa/pcm/dmix.conf /etc/alsa/pcm/dsnoop.conf A simple touch for both those files fixed the problem, and totem starts up normally again. Now i've done a clean test1 install (and upgraded to rawhide/development recent), and the soundcard (SB Audigy clasic, with digital out in use) is configured perfectly too (unlike before when it only configured analog out which i don't use), and system-config-soundcard playes test sounds and everything fine too. So what exactly does totem (or gstreamer?) need those files for, and why weren't they generated in the first place if their so crucial? :-) -- Chris -------------- 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 stransky at redhat.com Fri Jan 13 16:22:26 2006 From: stransky at redhat.com (Martin Stransky) Date: Fri, 13 Jan 2006 17:22:26 +0100 Subject: Weird totem/gstreamer crash caused by missing alsa config files? In-Reply-To: <1137168897.1951.8.camel@localhost.localdomain> References: <1137168897.1951.8.camel@localhost.localdomain> Message-ID: <43C7D3C2.3030603@redhat.com> You need to re-login after alsa-lib update. It's bug in alsa-lib and it's fixed in devel now. Ma. Chris Chabot wrote: > Hey all, > > On my box here totem would crash the moment it started up every time > with the error: > > An error occured > Could not open resource for writing > > Kind of cryptic and completely lacking of any helpfull meaning of what > resource it is trying to open for writing, so after discounting other > options (gstreamer dependencies, etc) i fired up strace and tried to > find what file opens failed. > > After wading thru tons of strace info using: > # strace -e trace=file /usr/bin/totem > > I noticed that the final file opens that failed before giving that error > were for: > /etc/alsa/pcm/dmix.conf > /etc/alsa/pcm/dsnoop.conf > > > A simple touch for both those files fixed the problem, and totem starts > up normally again. > > Now i've done a clean test1 install (and upgraded to rawhide/development > recent), and the soundcard (SB Audigy clasic, with digital out in use) > is configured perfectly too (unlike before when it only configured > analog out which i don't use), and system-config-soundcard playes test > sounds and everything fine too. > > So what exactly does totem (or gstreamer?) need those files for, and why > weren't they generated in the first place if their so crucial? :-) > > -- Chris > > From bbbush.yuan at gmail.com Fri Jan 13 18:09:36 2006 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sat, 14 Jan 2006 02:09:36 +0800 Subject: Will gnome-mount read /usr/share/hal/fdi/ policy files? Message-ID: <76e72f800601131009q5d3ce535o@mail.gmail.com> Hi, all Previously we use hal policy to set -o utf8 for vfat filesystem on block devices. It works well and fstab-sync can read it and set fstab accordingly. I wonder if gnome-mount will do this. Could anyone please kindly confirm it? Thanks! -- bbbush ^_^ From david at fubar.dk Fri Jan 13 19:26:15 2006 From: david at fubar.dk (David Zeuthen) Date: Fri, 13 Jan 2006 14:26:15 -0500 Subject: Will gnome-mount read /usr/share/hal/fdi/ policy files? In-Reply-To: <76e72f800601131009q5d3ce535o@mail.gmail.com> References: <76e72f800601131009q5d3ce535o@mail.gmail.com> Message-ID: <1137180376.4783.9.camel@daxter.boston.redhat.com> On Sat, 2006-01-14 at 02:09 +0800, Yuan Yijun wrote: > Hi, all > > Previously we use hal policy to set -o utf8 for vfat filesystem on > block devices. It works well and fstab-sync can read it and set fstab > accordingly. I wonder if gnome-mount will do this. Could anyone please > kindly confirm it? Thanks! No, in a future release settings will be read from gconf and there will also be UI integrated with e.g. Nautilus to configure these settings. David From gianluca.cecchi at gmail.com Fri Jan 13 19:31:11 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 13 Jan 2006 20:31:11 +0100 Subject: firefox i18n Message-ID: <561c252c0601131131ob2f436di@mail.gmail.com> Where are languages files for firefox? If I select italian language in my gnome session, firefox menu items are still in english. Gianluca From jspaleta at gmail.com Fri Jan 13 19:41:07 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 13 Jan 2006 14:41:07 -0500 Subject: Will gnome-mount read /usr/share/hal/fdi/ policy files? In-Reply-To: <1137180376.4783.9.camel@daxter.boston.redhat.com> References: <76e72f800601131009q5d3ce535o@mail.gmail.com> <1137180376.4783.9.camel@daxter.boston.redhat.com> Message-ID: <604aa7910601131141m261ab379y37835221a01b7f3f@mail.gmail.com> On 1/13/06, David Zeuthen wrote: > No, in a future release settings will be read from gconf and there will > also be UI integrated with e.g. Nautilus to configure these settings. how close to the future are we? Are we talking Max Headroom timscales: 20 minutes into the future? Or Asimov's Foundation timescale: sometime after we have populated the galaxy Or even further out at next Debian release timescales? -jef From david at fubar.dk Fri Jan 13 20:29:23 2006 From: david at fubar.dk (David Zeuthen) Date: Fri, 13 Jan 2006 15:29:23 -0500 Subject: Will gnome-mount read /usr/share/hal/fdi/ policy files? In-Reply-To: <604aa7910601131141m261ab379y37835221a01b7f3f@mail.gmail.com> References: <76e72f800601131009q5d3ce535o@mail.gmail.com> <1137180376.4783.9.camel@daxter.boston.redhat.com> <604aa7910601131141m261ab379y37835221a01b7f3f@mail.gmail.com> Message-ID: <1137184163.4783.15.camel@daxter.boston.redhat.com> On Fri, 2006-01-13 at 14:41 -0500, Jeff Spaleta wrote: > On 1/13/06, David Zeuthen wrote: > > No, in a future release settings will be read from gconf and there will > > also be UI integrated with e.g. Nautilus to configure these settings. > > how close to the future are we? > Are we talking Max Headroom timscales: 20 minutes into the future? > Or Asimov's Foundation timescale: sometime after we have populated the galaxy > Or even further out at next Debian release timescales? It's about 4-8 days of work (being conservative) but I'm not sure it's done before in a few months. It seems that most GNOME vendors definitely want something like this though so it's going to happen one way or another. Btw, this little project is a great way to get involved into the free software hacking so if there are any aspiring GNOME / freedesktop.org hackers out there send mail and patches to utopia-list at gnome.org and we'll try the best to guide you through this :-) Cheers, David From jspaleta at gmail.com Fri Jan 13 20:41:00 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 13 Jan 2006 15:41:00 -0500 Subject: Will gnome-mount read /usr/share/hal/fdi/ policy files? In-Reply-To: <1137184163.4783.15.camel@daxter.boston.redhat.com> References: <76e72f800601131009q5d3ce535o@mail.gmail.com> <1137180376.4783.9.camel@daxter.boston.redhat.com> <604aa7910601131141m261ab379y37835221a01b7f3f@mail.gmail.com> <1137184163.4783.15.camel@daxter.boston.redhat.com> Message-ID: <604aa7910601131241i14365412oc52100f1257234a0@mail.gmail.com> On 1/13/06, David Zeuthen wrote: > It's about 4-8 days of work (being conservative) but I'm not sure it's > done before in a few months. It seems that most GNOME vendors definitely > want something like this though so it's going to happen one way or > another. the change in how policy is being handled as thrown me for a real loop. I thought i was comfortable enough with how hal policy to generate my own policy additions.. now with the introduction of gnome-mount into rawhide I'm absolutely lost as to how this is suppose to work. The fact that the gnome-mount and hal documentation available in the rawhide packages are silent as to roadmap or the new structure really hurts my ability to grok what is going on, from a consumer perspective let alone a potential contributor to ui tools. -jef From caillon at redhat.com Fri Jan 13 20:53:26 2006 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 13 Jan 2006 15:53:26 -0500 Subject: firefox i18n In-Reply-To: <561c252c0601131131ob2f436di@mail.gmail.com> References: <561c252c0601131131ob2f436di@mail.gmail.com> Message-ID: <43C81346.5000503@redhat.com> On 01/13/2006 02:31 PM, Gianluca Cecchi wrote: > Where are languages files for firefox? > If I select italian language in my gnome session, firefox menu items > are still in english. > Gianluca > They are not available yet. Expect them sometime before test3. From david at fubar.dk Fri Jan 13 20:57:09 2006 From: david at fubar.dk (David Zeuthen) Date: Fri, 13 Jan 2006 15:57:09 -0500 Subject: Will gnome-mount read /usr/share/hal/fdi/ policy files? In-Reply-To: <604aa7910601131241i14365412oc52100f1257234a0@mail.gmail.com> References: <76e72f800601131009q5d3ce535o@mail.gmail.com> <1137180376.4783.9.camel@daxter.boston.redhat.com> <604aa7910601131141m261ab379y37835221a01b7f3f@mail.gmail.com> <1137184163.4783.15.camel@daxter.boston.redhat.com> <604aa7910601131241i14365412oc52100f1257234a0@mail.gmail.com> Message-ID: <1137185829.4783.17.camel@daxter.boston.redhat.com> On Fri, 2006-01-13 at 15:41 -0500, Jeff Spaleta wrote: > On 1/13/06, David Zeuthen wrote: > > It's about 4-8 days of work (being conservative) but I'm not sure it's > > done before in a few months. It seems that most GNOME vendors definitely > > want something like this though so it's going to happen one way or > > another. > > the change in how policy is being handled as thrown me for a real > loop. I thought i was comfortable enough with how hal policy to > generate my own policy additions.. now with the introduction of > gnome-mount into rawhide I'm absolutely lost as to how this is suppose > to work. The fact that the gnome-mount and hal documentation available > in the rawhide packages are silent as to roadmap or the new structure > really hurts my ability to grok what is going on, from a consumer > perspective let alone a potential contributor to ui tools. Oh, yea, I don't disagree it's going to be a little painful in the interim... but once we have the UI for doing this it's going to be a lot simpler than before. David From bbbush.yuan at gmail.com Fri Jan 13 21:15:54 2006 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sat, 14 Jan 2006 05:15:54 +0800 Subject: Will gnome-mount read /usr/share/hal/fdi/ policy files? In-Reply-To: <1137185829.4783.17.camel@daxter.boston.redhat.com> References: <76e72f800601131009q5d3ce535o@mail.gmail.com> <1137180376.4783.9.camel@daxter.boston.redhat.com> <604aa7910601131141m261ab379y37835221a01b7f3f@mail.gmail.com> <1137184163.4783.15.camel@daxter.boston.redhat.com> <604aa7910601131241i14365412oc52100f1257234a0@mail.gmail.com> <1137185829.4783.17.camel@daxter.boston.redhat.com> Message-ID: <76e72f800601131315q2a62da18j@mail.gmail.com> 2006/1/14, David Zeuthen : > > Oh, yea, I don't disagree it's going to be a little painful in the > interim... but once we have the UI for doing this it's going to be a lot > simpler than before. > yes, simpler if we can set the same policy with only one cmdline gconf-editor set vfat block option utf8. -- bbbush ^_^ From buildsys at redhat.com Sat Jan 14 08:36:26 2006 From: buildsys at redhat.com (Build System) Date: Sat, 14 Jan 2006 03:36:26 -0500 Subject: rawhide report: 20060114 changes Message-ID: <200601140836.k0E8aQ8v029434@porkchop.devel.redhat.com> Updated Packages: alsa-lib-1.0.11-2.rc2 --------------------- * Fri Jan 13 2006 Martin Stransky 1.0.11-2.rc2 - fix for #169729 - Kernel update makes snd-atiixp-modem & slmodemd fail - new ainit (0.7) should fix some problems with root users * Thu Jan 12 2006 Martin Stransky 1.0.11-1.rc2 - new upstream version anacron-2.3-35 -------------- * Wed Jan 11 2006 Peter Jones 2.3-35 - Fix initscript so changing runlevel shuts it down correctly bash-3.1-5 ---------- * Fri Jan 13 2006 Tim Waugh 3.1-5 - Fix 'exec -l /bin/bash'. * Thu Jan 12 2006 Tim Waugh 3.1-4 - Fix sighandler patch bug (bug #177545). * Tue Jan 10 2006 Tim Waugh 3.1-3 - Patchlevel 5. checkpolicy-1.28-5 ------------------ * Fri Jan 13 2006 Dan Walsh 1.28-5 - Rebuild to get latest libsepol control-center-1:2.13.4-2 ------------------------- * Fri Jan 13 2006 Matthias Clasen - 1:2.13.4-2 - Add a build requires for libXcursor-devel, to fix the mouse capplet. cups-1:1.1.23-29 ---------------- * Tue Jan 10 2006 Tim Waugh 1:1.1.23-29 - Apply dest-cache-v2 patch (bug #175847). desktop-printing-0.19-5 ----------------------- * Wed Jan 11 2006 John (J5) Palmieri - 0.19-5 - Add patch for fixing a crasher when plugging in a printer device-mapper-1.02.02-3 ----------------------- * Wed Jan 11 2006 Karel Zak - 1.02.02-3 - cleanup selinux patch - add pkg-config support * Fri Dec 09 2005 Jesse Keating - - 1.02.02-2.1 - rebuilt * Sat Dec 03 2005 Peter Jones - 1.02.02-2 - fix link path for libdevmapper-event.so dump-0.4b41-1 ------------- * Wed Jan 11 2006 Jindrich Novy 0.4b41-1 - update to 0.4b41 - drop .fixacl patch, now applied in the new upstream release - link against device-mapper elfutils-0.119-1 ---------------- * Fri Jan 13 2006 Roland McGrath - 0.119-1 - update to 0.119 elinks-0.11.0-2 --------------- * Tue Jan 10 2006 Karel Zak 0.11.0-2 - use upstream version of srcdir.patch * Tue Jan 10 2006 Karel Zak 0.11.0-1 - update to new upstream version - fix 0.11.0 build system (srcdir.patch) - regenerate patches: elinks-0.11.0-getaddrinfo.patch, elinks-0.11.0-ssl-noegd.patch, elinks-0.11.0-sysname.patch, elinks-0.11.0-union.patch * Fri Dec 09 2005 Jesse Keating 0.10.6-2.1 - rebuilt eog-2.13.4-1 ------------ * Fri Jan 13 2006 Matthias Clasen 2.13.4-1 - Update to 2.13.4 evolution-2.5.4-6 ----------------- * Thu Jan 12 2006 Christopher Aillon - 2.5.4-6 - Remove unneeded Requires: notify-daemon * Thu Jan 12 2006 Christopher Aillon - 2.5.4-5 - Update BR to libnotify-devel * Wed Jan 11 2006 David Malcolm - 2.5.4-4 - ported alarm notification code to the new libnotify API (patch 806, #177546) - added libnotify_support macro - added explicit notify-daemon requirement as a workaround for bug #177535 evolution-data-server-1.5.4-4 ----------------------------- * Mon Jan 09 2006 David Malcolm - 1.5.4-4 - updated patch 300 to remove usage of GNOME_COMPILE_WARNINGS from configure.in (since gnome-common might not be available when we rerun the autotools) * Mon Jan 09 2006 David Malcolm - 1.5.4-3 - added patch to make the "imap4"/"IMAP4rev1" backend optional; disable it in our packages; re-run automake since we have touched various Makefile.am files; rerun intltoolize to avoid incompatibilities between tarball copy of intltool-merge.in and intltool.m4 in intltool package (@EXPANDED_LIBDIR@ renamed to @INTLTOOL_LIBDIR@) (#167574) - explicitly list the camel providers and e-d-s extension files in the spec file file-4.16-5 ----------- * Fri Jan 13 2006 Radek Vokal 4.16-5 - fix for 64bit arrays findutils-1:4.2.27-2 -------------------- * Thu Jan 12 2006 Miloslav Trmac - 1:4.2.27-2 - Don't use uninitialized memory in -printf %Z (#174485) - Ship more documentation files - Clean up the spec file a bit flex-2.5.4a-35 -------------- * Fri Jan 13 2006 Petr Machata 2.5.4a-35 - Adding `std::' prefixes, got rid of `using namespace std'. (#115354) - Dummy use of `yy_flex_realloc' to silent warnings. (#30943) - Adding URL of flex home page to spec (#142675) ftp-0.17-32.1 ------------- * Thu Jan 12 2006 Petr Raszyk - 0.17-32 - support for multi-homed clients See #171621, netkit-ftp-0.17-multihome.patch gaim-1:1.5.0-13.fc5 ------------------- * Fri Jan 13 2006 Warren Togami 1:1.5.0-13 - buildreq desktop-file-utils (ivazquez #176688) - detect NSS in a generic way and abort on failure gdm-1:2.13.0.4-3 ---------------- * Fri Jan 13 2006 Ray Strode - 1:2.13.0.4-3 - migrate X server configuration for pre-modular X configurations. Problems reported by Dennis Gregorovic gedit-1:2.13.2-1 ---------------- * Fri Jan 13 2006 Matthias Clasen - 1.2.13.2-1 - Update to 2.13.2 - Update the persistent file selector size patch (again!) gnome-mount-0.3-1 ----------------- gnome-pilot-conduits-2.0.13-3.FC5 --------------------------------- * Wed Jan 11 2006 David Malcolm - 2.0.13-3.FC5 - extend patch 2 to handle a missing fix in the email conduit, renaming it from gnome-pilot-conduits-2.0.12-port-to-pilot-link-0.12.patch to gnome-pilot-conduits-2.0.13-port-to-pilot-link-0.12.patch in the process (#159165) gnome-screensaver-0.0.24-1 -------------------------- * Fri Jan 13 2006 Matthias Clasen - 0.0.24-1 - Update to 0.0.24 gnome-session-2.13.4-1 ---------------------- * Fri Jan 13 2006 Matthias Clasen - 2.13.4-1 - Update to 2.13.4 * Thu Jan 12 2006 Ray Strode - 2.12.0-6 - Fix screen corruption around splash screen shape (bug 177502) gnome-terminal-2.13.1-1 ----------------------- * Fri Jan 13 2006 Matthias Clasen 2.13.1-1 - Update to 2.13.1 - Remove upstreamed patches gnome-volume-manager-1.5.9-1 ---------------------------- * Fri Jan 13 2006 Matthias Clasen - 1.5.9-1 - Update to 1.5.9 gnucash-1.8.12-2 ---------------- * Fri Jan 13 2006 Bill Nottingham 1.8.12-2 - disable postgres backend (#177646) gphoto2-2.1.99-3 ---------------- * Fri Jan 13 2006 Radek Vokal 2.1.99-3 - export LIBDIR before creating .fdi file * Fri Jan 13 2006 Radek Vokal 2.1.99-2 - spec file clean-up - use ./print-usb-map - docs are back in -devel package groff-1.18.1.1-8 ---------------- * Thu Jan 12 2006 Miroslav Lichvar - 1.18.1.1-8 - fix segfault in grotty on 64-bit big endian machines (#176904) - fix assertion failure on abort message (#141912) - attempt to fix a space problem with several european languages (#137728) grub-0.97-2 ----------- * Fri Jan 13 2006 Peter Jones - 0.97-2 - add dmraid support gtk2-2.8.10-2 ------------- * Fri Jan 13 2006 Matthias Clasen 2.8.10-2 - Run make check * Thu Jan 12 2006 Matthias Clasen 2.8.10-1 - Update to 2.8.10 hal-0.5.5.1.cvs20060111-1 ------------------------- * Wed Jan 11 2006 Christopher Aillon - 0.5.5.1.cvs20060111-1 - Update to an even newer CVS snapshot, to fix privelege escalation issue - Remove mount options patch (upstreamed already) hal-cups-utils-0.5.5-1 ---------------------- * Thu Jan 12 2006 Christopher Aillon - 0.5.5-1 - New version, which makes sure we build the daemon with PIE hicolor-icon-theme-0.9-1 ------------------------ * Thu Jan 12 2006 Alexander Larsson 0.9-1 - Update to 0.9, fixes scalable icons picked before bitmap icons kernel-2.6.15-1.1853_FC5 ------------------------ * Sat Jan 14 2006 David Woodhouse - Make CHRP build again * Fri Jan 13 2006 David Woodhouse - Update softmac and add WPA support to bcm43xx driver - 2.6.15-git9 * Fri Jan 13 2006 David Woodhouse - Add TIF_RESTORE_SIGMASK patches. - Fix I/O queue stalls lftp-3.4.0-1 ------------ * Fri Jan 13 2006 Jason Vas Dias - 3.4.0-1 - Upgrade to upstream version 3.4.0 libdrm-2.0-2 ------------ * Wed Jan 11 2006 Mike A. Harris 2.0-2 - Replaced the temporary tongue-in-cheek humourous package summary and description with the proper package descriptions, as many people didn't get the joke, while others felt it was getting old. Ah well, I had my fun for a while anyway. ;o) libgdiplus-1.1.13-1 ------------------- * Fri Jan 13 2006 Alexander Larsson - 1.1.13-1 - update to 1.1.13 * Wed Jan 11 2006 Alexander Larsson 1.1.11-2 - Don't package debug info libiec61883-1.0.0-10.fc5 ------------------------ * Fri Dec 30 2005 Jarod Wilson 1.0.0-10 - Add missing autoconf, automake and libtool BuildRequires libnotify-0.3.0-4 ----------------- * Thu Jan 12 2006 Christopher Aillon - 0.3.0-4 - Require a desktop-notification-daemon to be present. Currently, this is notify-daemon, but libnotify doesn't specifically require that one. Require 'desktop-notification-daemon' which daemons providing compatible functionality are now expected to provide. librsvg2-2.13.5-1 ----------------- * Fri Jan 13 2006 Matthias Clasen 2.13.5-1 - Update to 2.13.5 libselinux-1.29.5-2 ------------------- * Fri Jan 13 2006 Dan Walsh 1.29.5-2 - Split out pywrap in Makefile * Fri Jan 13 2006 Dan Walsh 1.29.5-1 - Upgrade to latest from NSA * Added getseuser test program. libsemanage-1.5.14-2 -------------------- * Fri Jan 13 2006 Dan Walsh 1.5.14-2 - Break out python out of regular Makefile * Fri Jan 13 2006 Dan Walsh 1.5.14-1 - Upgrade to latest from NSA * Merged disallow port overlap patch from Ivan Gyurdiev. * Merged join prereq and implementation patches from Ivan Gyurdiev. * Merged join user extra data part 2 patch from Ivan Gyurdiev. * Merged bugfix patch from Ivan Gyurdiev. * Merged remove add_local/set_local patch from Ivan Gyurdiev. * Merged user extra data part 1 patch from Ivan Gyurdiev. * Merged size_t -> unsigned int patch from Ivan Gyurdiev. * Merged calloc check in semanage_store patch from Ivan Gyurdiev, bug noticed by Steve Grubb. * Merged cleanups after add/set removal patch from Ivan Gyurdiev. libsepol-1.11.9-1 ----------------- * Fri Jan 13 2006 Dan Walsh 1.11.9-1 - Upgrade to latest from NSA * Merged size_t -> unsigned int patch from Ivan Gyurdiev. * Tue Jan 10 2006 Dan Walsh 1.11.8-1 - Upgrade to latest from NSA * Merged 2nd const in APIs patch from Ivan Gyurdiev. libsetrans-0.1.17-1 ------------------- * Wed Jan 11 2006 Dan Walsh 0.1.17-1 - Fix range translations linuxwacom-0:0.7.2-1 -------------------- * Fri Jan 13 2006 Kristian H??gsberg 0:0.7.2-1 - Update to version 0.7.2. - Drop linuxwacom-0.6.4-linux-input.patch since the kernel headers now define EV_SYN. - Update SDK patch to work with new modular paths. mailman-3:2.1.7-1 ----------------- * Tue Jan 10 2006 Harald Hoyer - 3:2.1.7-1 - version 2.1.7 metacity-2.13.13-1 ------------------ * Fri Jan 13 2006 Matthias Clasen 2.13.13-1 - Update to 2.13.13 mono-1.1.13-1 ------------- * Fri Jan 13 2006 Alexander Larsson - 1.1.13-1 - Update to 1.13 - Add libgdiplus dep to mono-core - Add s390x to build nfs-utils-1.0.8.rc2-2.FC5 ------------------------- * Wed Jan 11 2006 Peter Jones 1.0.8.rc2-2.FC5 - Fix lockfile naming in the initscripts so they're stopped correctly. notify-daemon-0.3.1-4 --------------------- * Thu Jan 12 2006 Christopher Aillon - 0.3.1-4 - Provide desktop-notification-daemon, since libnotify requires a notification deamon, but not this specific one. Other notification daemons can exist on the system so long as they meet the provides (and the API of course). nss_ldap-245-1 -------------- * Wed Jan 11 2006 Nalin Dahyabhai 245-1 - update to nss_ldap 245 - add patch from upcoming 246 release to change the placeholder used when userPassword is unreadable from "x" to "*" (upstream #240) perl-Devel-Symdump-2.05-1 ------------------------- * Tue Jan 10 2006 Jason Vas Dias - 2.05-1 - fix bug 176718: Upgrade to 2.05 perl-File-MMagic-1.25-1 ----------------------- * Tue Jan 10 2006 Jason Vas Dias - 1.25-1 - fix bug 176717: upgrade to 1.25 perl-HTML-Tagset-3.10-1 ----------------------- * Tue Jan 10 2006 Jason Vas Dias - 3.10-1 - fix bug 176720: upgrade to 3.10 - make .spec file conform to fedora-rpmdevtools spectemplate-perl.spec perl-RPM-Specfile-1.19-1 ------------------------ * Fri Jan 06 2006 Ville Skytt?? - 1.19-1 - 1.19 (#176721). - Rewrite specfile using fedora-rpmdevtools' spec template, fixes #176888. * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-String-CRC32-1.3-1.4.FC5 ----------------------------- perl-XML-Grove-0.46alpha-29 --------------------------- * Fri Jan 06 2006 Ville Skytt?? - 0.46alpha-29 - Rewrite specfile using fedora-rpmdevtools' spec template, fixes #176889. - Fix License, include docs. * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj php-5.1.2-2 ----------- * Fri Jan 13 2006 Joe Orton 5.1.2-2 - update to 5.1.2 php-pear-1:1.4.5-6 ------------------ * Fri Dec 30 2005 Tim Jackson 1:1.4.5-6 - Patches to fix "pear makerpm" policycoreutils-1.29.7-2 ------------------------ * Sat Jan 14 2006 Dan Walsh 1.29.7-2 - Add ivans patch * Fri Jan 13 2006 Dan Walsh 1.29.7-1 - Update to match NSA * Merged newrole cleanup patch from Steve Grubb. * Merged setfiles/restorecon performance patch from Russell Coker. * Merged genhomedircon and semanage patches from Dan Walsh. * Merged remove add_local/set_local patch from Ivan Gyurdiev. poppler-0.5.0-2.0 ----------------- * Wed Jan 11 2006 Kristian H??gsberg - 0.5.0-2.0 - Update to 0.5.0 and add poppler-utils subpackage. - Flesh out poppler-utils subpackage. * Fri Dec 09 2005 Jesse Keating - rebuilt readahead-1:1.2-1.23.1 ---------------------- * Fri Jan 13 2006 Karel Zak - check & cleanup list of files by readahead-gen script redhat-artwork-0.131-3 ---------------------- * Fri Jan 13 2006 Christopher Aillon 0.131-3 - BuildRequire xorg-x11-apps, as xcursorgen moved there. This should really really fix the cursors issue. redhat-lsb-3.0-9 ---------------- * Fri Jan 13 2006 Leon Ho 3.0-9 - Migrated back to rawhide * Wed Aug 03 2005 Leon Ho 3.0-8.EL - Added libstdc++.so.6/libGL.so.1 requirement (RH#154605) * Wed Aug 03 2005 Leon Ho 3.0-7.EL - Fixed multilib problem on lsb_release not to read /etc/lsb-release and solely depends on /etc/lsb-release.d/ (Advised by LSB committee) - Removed /etc/lsb-release (Advised by LSB committee) rhpxl-0.10-1 ------------ * Wed Jan 11 2006 Peter Jones 0.10-1 - If we're on a Mac and can't get DDC/EDID, and our resolution is tiny, force 1024x768. rpm-4.4.2-13 ------------ * Wed Jan 11 2006 Paul Nasrat - 4.4.2-13 - Don't mmap large files selinux-policy-2.1.10-1 ----------------------- * Fri Jan 13 2006 Dan Walsh 2.1.10-1 - Update to upstream stardict-2.4.5-2 ---------------- * Fri Jan 13 2006 Leon Ho 2.4.5-2 - added in patch to fix #176890 * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-bind-4.0.0-36_FC5 ------------------------------- * Tue Jan 10 2006 Jason Vas Dias - 4.0.0-36 - fix bug 176142 (final!) : ship the Serbian translations - fix str widget save (TXT records) system-config-display-1.0.35-1 ------------------------------ * Thu Jan 12 2006 Soren Sandmann - 1.0.35-1 - Rebuild * Tue Jan 10 2006 Soren Sandmann - 1.0.34-1 - Some s/rhpl/rhpxl/ type changes * Mon Nov 14 2005 Jeremy Katz - 1.0.33-1 - minor changes needed for modular X system-config-printer-0.6.148-1 ------------------------------- * Tue Jan 10 2006 Tim Waugh 0.6.148-1 - Don't remove the cache directory, only its contents (bug #177266). system-config-soundcard-1.2.14-2 -------------------------------- * Thu Jan 12 2006 Martin Stransky 1.2.14-2 - added patch for menu entries (#177479) tetex-3.0-14 ------------ * Wed Jan 11 2006 Jindrich Novy 3.0-14 - apply additional patch to fix xpdf flaws from Ludwig Nussel (CVE-2005-3191, CVE-2005-3192 and CVE-2005-3193) (#177128) - /usr/share/texmf/doc is now owned by tetex package (#177065) - update searching order for kpathsea (local texmf tree is searched first) thunderbird-0:1.5-1 ------------------- * Thu Jan 12 2006 Christopher Aillon - 1.5-1 - Official 1.5 release is out * Wed Jan 11 2006 Christopher Aillon - 1.5-0.5.6.rc1 - Fix crash when deleting highlighted text while composing mail within plaintext editor with spellcheck enabled. tomboy-0.3.3-5 -------------- * Fri Jan 13 2006 Alexander Larsson 0.3.3-5 - Add gtkspell requirement tzdata-2005r-3 -------------- * Thu Jan 12 2006 Petr Machata 2005r-3 - 2005r-3 - Meta changes. Renaming tzdata.tar.bz2 file to tzdata$ver-base, so that it won't clash across updates. vixie-cron-4:4.1-44.FC5 ----------------------- * Tue Jan 10 2006 Jason Vas Dias - fix bug 177476: make minder/mailer process run as job user with user context; re-organize PAM and SELinux code vsftpd-2.0.4-1 -------------- * Thu Jan 12 2006 Radek Vokal 2.0.4-1 - upgrade to 2.0.4 - vsftpd now lock files for simultanous up/downloads (#162511) xpdf-1:3.01-7 ------------- * Tue Jan 10 2006 Karsten Hopp 3.01-7 - add patches to fix CVE-2005-3191 and CAN-2005-3193 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 systemtap - 0.5.2-2.i386 requires libdw.so.1(ELFUTILS_0.118) Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs systemtap - 0.5.2-2.ia64 requires libdw.so.1(ELFUTILS_0.118)(64bit) Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.1.ppc requires ccs = 0:1.0.2-3.1 gulm - 1.0.4-2.FC5.1.ppc requires ccs systemtap - 0.5.2-2.ppc requires libdw.so.1(ELFUTILS_0.118) Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 systemtap - 0.5.2-2.ppc64 requires libdw.so.1(ELFUTILS_0.118)(64bit) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires libdw.so.1(ELFUTILS_0.118) systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires libdw.so.1(ELFUTILS_0.118)(64bit) systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 systemtap - 0.5.2-2.x86_64 requires libdw.so.1(ELFUTILS_0.118)(64bit) From gianluca.cecchi at gmail.com Sat Jan 14 09:59:27 2006 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Sat, 14 Jan 2006 10:59:27 +0100 Subject: firefox i18n Message-ID: <561c252c0601140159t69771d1bv@mail.gmail.com> On 01/13/2006, Christopher Aillon wrote: >They are not available yet. Expect them sometime before test3. If I may contribute in some way, at least for the italian part, if they don't need programming skills, I am available. From thomas at apestaart.org Sat Jan 14 09:58:12 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sat, 14 Jan 2006 10:58:12 +0100 Subject: totem great instability In-Reply-To: <561c252c0601121321n583aedfbt@mail.gmail.com> References: <561c252c0601121321n583aedfbt@mail.gmail.com> Message-ID: <1137232692.3599.30.camel@otto> On Thu, 2006-01-12 at 22:21 +0100, Gianluca Cecchi wrote: > Not considering the fact that you are able to play near nothing with > it, Depends on how much you add to the install. It plays more than the mplayer/vlc/xine that is in fedora, given that they're not there :) > The latest totem-1.3.0-3, while navigating through file system, often > freezes Do you mean that these freezes happen in the file selector ? Do you see the same freezes when navigating the file system with other gtk-based applications, like, say, gedit ? If so, it sounds like a fileselector problem - make sure to file a bug upstream. > and > doing strace of pid gives continuously something like what below. Not sure why you're copying a meaningless strace output snippet. What were you doing in totem while strace'ing ? It looks to be in a glib mainloop (see poll) which is fine, because you're running a GNOME app. The shmctl could be anything - for example, X shared memory being copied. > Does it make sens to include totem in core, when every one that wants to see > videos in fedora, removes totem and installs then totem-xine (plus > decoding/navigating > libraries) or other similar applications like mplayer or vlc? Not everyone does. If you feel mplayer provides you with a richer user experience, please do so. But other people want to work towards an end solution that can be distributed. Mplayer/vlc/xine aren't it. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> ik kon liegen ik kon jou bedriegen mezelf verraden zonder spijt <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From bbbush.yuan at gmail.com Sat Jan 14 09:45:06 2006 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sat, 14 Jan 2006 17:45:06 +0800 Subject: bash 3.1 gotcha In-Reply-To: <1137144066.3902.5.camel@localhost.localdomain> References: <1137093984.4507.26.camel@localhost.localdomain> <20060112193155.GF1547370@hiwaay.net> <1137143634.3902.1.camel@localhost.localdomain> <1137144066.3902.5.camel@localhost.localdomain> Message-ID: <76e72f800601140145h49f32465j@mail.gmail.com> 2006/1/13, Callum Lerwick : > > Or wait, maybe it is. But its doing some fancy mangling to keep it all > on one line... > > Waaa! only the first command after login or su will be all on one line and the next ones will not, which is very very strange! When is bash set its terminal width, not right before prompt is drawn? -- bbbush ^_^ From bart.vanbrabant at zoeloelip.be Sat Jan 14 11:26:07 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Sat, 14 Jan 2006 12:26:07 +0100 Subject: removing kernel-devel rpms Message-ID: <43C8DFCF.7020601@zoeloelip.be> Hello, A few weeks back I installed xen and the kernels needed to run it. These kernels where to old to run the new udev and stuff like that so I removed them. I managed to remove them all except kernel-xen-hypervisor-devel. Now when I try to remove this package or any other kernel-devel package rpm starts to use 100% cpu and eating up all my memory (no swapping) and that's it. I have to kill it with kill -9. I also tried removing it with yum but this gives the same result. When I run rpm with -vvv I get this output: D: opening db environment /var/lib/rpm/Packages joinenv D: opening db index /var/lib/rpm/Packages rdonly mode=0x0 D: locked db index /var/lib/rpm/Packages D: opening db index /var/lib/rpm/Name rdonly mode=0x0 D: read h# 495 Header SHA1 digest: OK (ac5184f6a47674edad14c13ec3ada90fbccdbe0f) D: ========== --- kernel-devel-2.6.14-1.1805_FC5 i686/linux 0x0 D: opening db index /var/lib/rpm/Requirename rdonly mode=0x0 D: ========== recording tsort relations D: ========== tsorting packages (order, #predecessors, #succesors, tree, depth, breadth) D: 0 0 0 0 1 0 -kernel-devel-2.6.14-1.1805_FC5.i686 D: closed db index /var/lib/rpm/Requirename D: closed db index /var/lib/rpm/Name D: closed db index /var/lib/rpm/Packages D: closed db environment /var/lib/rpm/Packages D: opening db environment /var/lib/rpm/Packages joinenv D: opening db index /var/lib/rpm/Packages create mode=0x42 D: mounted filesystems: D: i dev bsize bavail iavail mount point D: 0 0x00001602 4096 2011197 2541260 / D: 1 0x00000003 4096 0 -1 /proc D: 2 0x00000000 4096 0 -1 /sys D: 3 0x0000000a 4096 0 -1 /dev/pts D: 4 0x00000012 4096 129398 129397 /dev/shm D: 5 0x00001605 4096 1693426 27282253 /home D: 6 0x00000013 4096 0 -1 /proc/sys/fs/binfmt_misc D: 7 0x00000014 4096 0 -1 /var/lib/nfs/rpc_pipefs D: 8 0x00001601 8192 648695 -1 /media/WINDOWS D: sanity checking 1 elements D: running pre-transaction scripts D: computing 7898 file fingerprints D: computing file dispositions D: opening db index /var/lib/rpm/Basenames create mode=0x42 Here it stops doing stuff. When I try to remove a package for the first time I see a lot of hd activity first before I goes to 100% cpu usage. The second time I try it does it directly. I tried rebuilding my rpm database. Also by first removing the __db* files in /var/lib/rpm/ but that doesn't work either. Is there a way to remove this packages? Because I start to get quite some kernel-devel packages and it's probably a bug. thanks, Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mike at miketc.com Sat Jan 14 13:01:22 2006 From: mike at miketc.com (Mike Chambers) Date: Sat, 14 Jan 2006 07:01:22 -0600 Subject: removing kernel-devel rpms In-Reply-To: <43C8DFCF.7020601@zoeloelip.be> References: <43C8DFCF.7020601@zoeloelip.be> Message-ID: <1137243682.3439.0.camel@scrappy.miketc.com> On Sat, 2006-01-14 at 12:26 +0100, Bart Vanbrabant wrote: > A few weeks back I installed xen and the kernels needed to run it. These > kernels where to old to run the new udev and stuff like that so I > removed them. I managed to remove them all except > kernel-xen-hypervisor-devel. Now when I try to remove this package or > any other kernel-devel package rpm starts to use 100% cpu and eating up > all my memory (no swapping) and that's it. I have to kill it with kill -9. > I also tried removing it with yum but this gives the same result. You try removing the kernel-devel packages by version (one by one) instead of the whole thing? yum remove kernel-devel-1.2.3 -- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt, then it's hilarious!" From bart.vanbrabant at zoeloelip.be Sat Jan 14 13:13:27 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Sat, 14 Jan 2006 14:13:27 +0100 Subject: removing kernel-devel rpms In-Reply-To: <1137243682.3439.0.camel@scrappy.miketc.com> References: <43C8DFCF.7020601@zoeloelip.be> <1137243682.3439.0.camel@scrappy.miketc.com> Message-ID: <43C8F8F7.7040605@zoeloelip.be> Mike Chambers wrote: > On Sat, 2006-01-14 at 12:26 +0100, Bart Vanbrabant wrote: > > >> A few weeks back I installed xen and the kernels needed to run it. These >> kernels where to old to run the new udev and stuff like that so I >> removed them. I managed to remove them all except >> kernel-xen-hypervisor-devel. Now when I try to remove this package or >> any other kernel-devel package rpm starts to use 100% cpu and eating up >> all my memory (no swapping) and that's it. I have to kill it with kill -9. >> I also tried removing it with yum but this gives the same result. >> > > You try removing the kernel-devel packages by version (one by one) > instead of the whole thing? > > yum remove kernel-devel-1.2.3 > > Yeah, that the way I do it. Mostly I do it with rpm -e so I need to specify the version to remove. The debug output of rpm is when I specified a package. -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ndbecker2 at gmail.com Sat Jan 14 14:25:04 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 14 Jan 2006 09:25:04 -0500 Subject: Why not /usr/bin64? Message-ID: On multi-arch, e.g. x86_64, we have /usr/lib for 32bit and /usr/lib64 for 64bit. We should have a place for 32bit and 64bit bins. To be consistent, 64bit would go in /usr/bin64. This would cause massive problems for all the apps that expect to look in /usr/bin. Here are 2 proposals: 1) 32bit in /usr/bin32, 64bit in /usr/bin64, and /usr/bin->/usr/bin64 2) 32bit in /usrbin32, 64bit in /usr/bin From naheemzaffar at gmail.com Sat Jan 14 15:39:10 2006 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 14 Jan 2006 15:39:10 +0000 Subject: totem great instability In-Reply-To: <1137232692.3599.30.camel@otto> References: <561c252c0601121321n583aedfbt@mail.gmail.com> <1137232692.3599.30.camel@otto> Message-ID: <3adc77210601140739j7be81681mb929488196550725@mail.gmail.com> Just as a side note, todays totem is the first one that has successfully worked for me in a long while. Before it used to freeze at start-up, and after the gstreamer update, it just said could not write to resource or something. Today it works. And gstreamer's plugin architecture allows it to add any functionality not provided by default. As far as I know, only one rpm needs to be added now for most non-fre formats. Lets just hope the totem web plugin also come along (it is in development...). Otherwise Mplayer is still needed for that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at adslpipe.co.uk Sat Jan 14 16:02:07 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sat, 14 Jan 2006 16:02:07 +0000 Subject: ugly cursor? How did the story end? In-Reply-To: <561c252c0601121411n319f21a5l@mail.gmail.com> References: <561c252c0601121411n319f21a5l@mail.gmail.com> Message-ID: <43C9207F.9030107@adslpipe.co.uk> Gianluca Cecchi wrote: > from system---> preferences ---> mouse ---> cursor tab, there are no > themes installable > And the default I have is ugly (old days clock and old-old days white hand): > so these will be the default and only usable mouse-themes? Fixed as of rawhide 2006-01-14 From fedora at camperquake.de Sat Jan 14 16:09:05 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 14 Jan 2006 17:09:05 +0100 Subject: Why not /usr/bin64? In-Reply-To: References: Message-ID: <43C92221.3020505@camperquake.de> Neal Becker schrieb: > 1) 32bit in /usr/bin32, 64bit in /usr/bin64, and /usr/bin->/usr/bin64 > 2) 32bit in /usrbin32, 64bit in /usr/bin Nice solution. However, what exactly is the problem that this solves? From ellson at research.att.com Sat Jan 14 16:18:20 2006 From: ellson at research.att.com (John Ellson) Date: Sat, 14 Jan 2006 11:18:20 -0500 Subject: rawhide report: 20060114 changes - NVIDIA driver fix In-Reply-To: References: <200601140836.k0E8aQ8v029434@porkchop.devel.redhat.com> Message-ID: <43C9244C.8040506@research.att.com> Justin Conover wrote: > On 1/14/06, Build System wrote: > >> >> >> Updated Packages: >> >> kernel-2.6.15-1.1853_FC5 >> ------------------------ >> * Sat Jan 14 2006 David Woodhouse >> - Make CHRP build again >> >> * Fri Jan 13 2006 David Woodhouse >> - Update softmac and add WPA support to bcm43xx driver >> - 2.6.15-git9 >> >> * Fri Jan 13 2006 David Woodhouse >> - Add TIF_RESTORE_SIGMASK patches. >> - Fix I/O queue stalls >> >> >> > Could any of this affect how nvidia (closed source drivers are installed)? > I know closed source drivers aren't supported, so please don't turn this > into a flamefest, but I would appreciate how I can tell yum not to remove > kernels. > > kernel-2.6.15-1.1826.2.10_FC5 > kernel-devel-2.6.15-1.1826.2.10_FC5 > > Works just fine and I really need my dual screens(twinview) so if you can > tell me how I can keep those two packages I would appreciate it. > > Thank you, > > BTW There is a patch for the NVIDIA problem in the thread: http://www.nvnews.net/vbulletin/showthread.php?t=62889 John From arjan at fenrus.demon.nl Sat Jan 14 16:23:37 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 14 Jan 2006 17:23:37 +0100 Subject: mixer_applet2 (was Re: rawhide report: 20060106 changes) In-Reply-To: References: <200601061016.k06AGqLC010992@porkchop.devel.redhat.com> Message-ID: <1137255817.3014.36.camel@laptopd505.fenrus.org> On Sat, 2006-01-14 at 10:16 -0600, Justin Conover wrote: > > > On 1/6/06, Build System wrote: > > gnome-applets-1:2.13.1-4 > ------------------------ > * Thu Jan 05 2006 John (J5) Palmieri > 2.13.1-4 > - GStreamer has been split into gstreamer08 and gstreamer > ( 0.10) packages > we need gstreamer08 for now > > gnome-panel-2.13.4-1 > -------------------- > * Thu Jan 05 2006 Matthias Clasen > 2.13.4-1 > - Update to 2.13.4 > - reinstate the desktop-menu-renaming > > > This is odd that I'm just now seeing this today, but mixer_applet2 > keeps crash with: > > "THe Application "mixer_applet2" has quit unexpectedly." semi related question; has anyone converted mixer_applet2 to use alsa yet? The kernel keeps moaning about it in fc4 at least... From ndbecker2 at gmail.com Sat Jan 14 18:07:24 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 14 Jan 2006 13:07:24 -0500 Subject: Why not /usr/bin64? References: <43C92221.3020505@camperquake.de> Message-ID: Ralf Ertzinger wrote: > Neal Becker schrieb: > >> 1) 32bit in /usr/bin32, 64bit in /usr/bin64, and /usr/bin->/usr/bin64 >> 2) 32bit in /usrbin32, 64bit in /usr/bin > > Nice solution. However, what exactly is the problem that this solves? > Meant /usr/bin32. Anyway, problem is how to install both 64 and 32 bit versions of your favorite app. Like, mozilla. We x86_64 64bit users often have to install a 32bit browser so that 32bit plugins will work. From icon at fedoraproject.org Sat Jan 14 18:23:12 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sat, 14 Jan 2006 13:23:12 -0500 Subject: PHP requiring Apache Message-ID: <43C94190.3000906@fedoraproject.org> Hello, all: Summary: PHP should not require Apache, since it may not be used with Apache. Apache-specific bits of PHP should therefore be moved to a sub-package. Problem: Currently php packages require apache. It's an artificial requirement, since PHP does not depend on apache to run, and moreover, sometimes PHP can be used without Apache, for example when it's used with another server such as lighttpd, or in CGI mode with other applications. There are also places that write shell scripts in PHP, since it's "familiar to everyone who has to support them." Yes, I'm in one of such places, sadly. Suggestion: So that apache doesn't get installed as dead weight in configurations where PHP is used without it, the bits and pieces of PHP that actually deal with Apache should be moved to a separate sub-package. Thoughts? (Other than "php must die?") Regards, -- Konstantin Ryabitsev McGill University WSG Montr?al, Qu?bec From admin at ramshacklestudios.com Sat Jan 14 18:55:27 2006 From: admin at ramshacklestudios.com (Peter Gordon) Date: Sat, 14 Jan 2006 10:55:27 -0800 Subject: PHP requiring Apache In-Reply-To: <43C94190.3000906@fedoraproject.org> References: <43C94190.3000906@fedoraproject.org> Message-ID: <1137264927.9959.15.camel@tuxhugger> On Sat, 2006-01-14 at 13:23 -0500, Konstantin Ryabitsev wrote: > Suggestion: > So that apache doesn't get installed as dead weight in > configurations where PHP is used without it, the bits and pieces of > PHP that actually deal with Apache should be moved to a separate > sub-package. > > Thoughts? (Other than "php must die?") Perhaps a separate "mod_php" package could be split from the main PHP tarball? -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 -------------- 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 jkeating at j2solutions.net Sat Jan 14 20:14:57 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 14 Jan 2006 15:14:57 -0500 Subject: PHP requiring Apache In-Reply-To: <43C94190.3000906@fedoraproject.org> References: <43C94190.3000906@fedoraproject.org> Message-ID: <1137269697.2901.6.camel@ender> On Sat, 2006-01-14 at 13:23 -0500, Konstantin Ryabitsev wrote: > > Suggestion: > So that apache doesn't get installed as dead weight in > configurations where PHP is used without it, the bits and pieces of > PHP that actually deal with Apache should be moved to a separate > sub-package. > > Thoughts? (Other than "php must die?") Seems reasonable, should be a RFE in bugzilla (; -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 jos at xos.nl Sat Jan 14 21:03:22 2006 From: jos at xos.nl (Jos Vos) Date: Sat, 14 Jan 2006 22:03:22 +0100 Subject: Why not /usr/bin64? In-Reply-To: ; from ndbecker2@gmail.com on Sat, Jan 14, 2006 at 09:25:04AM -0500 References: Message-ID: <20060114220322.A21342@xos037.xos.nl> On Sat, Jan 14, 2006 at 09:25:04AM -0500, Neal Becker wrote: > On multi-arch, e.g. x86_64, we have /usr/lib for 32bit and /usr/lib64 for > 64bit. We should have a place for 32bit and 64bit bins. To be consistent, > 64bit would go in /usr/bin64. This would cause massive problems for all > the apps that expect to look in /usr/bin. Here are 2 proposals: > > 1) 32bit in /usr/bin32, 64bit in /usr/bin64, and /usr/bin->/usr/bin64 > 2) 32bit in /usrbin32, 64bit in /usr/bin First, this is an issue to be discussed within the LSB community, not in the Fedora community. Some more comments (assuming in (2) you meant /usr/bin32): - As you point out yourself, apps expect to look in /usr/bin. So both suggestions cause problems to find apps that are only available in 32-bit format, which is a serious problem. - In case (2), 32-bit packages would have to be built twice: one time for 32-bit systems and one time for 64-bit systems. - The issue with 32-bit apps is in a lot of cases to support third party 32-bit software software on 64-bit systems. Option (1) conflicts with with this and it is important to realize that third party vendors will in most cases not provide two versions of 32-bit packages. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From Axel.Thimm at ATrpms.net Sat Jan 14 21:32:10 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 14 Jan 2006 22:32:10 +0100 Subject: Why not /usr/bin64? In-Reply-To: References: <43C92221.3020505@camperquake.de> Message-ID: <20060114213210.GF10980@neu.nirvana> On Sat, Jan 14, 2006 at 01:07:24PM -0500, Neal Becker wrote: > Ralf Ertzinger wrote: > > > Neal Becker schrieb: > > > >> 1) 32bit in /usr/bin32, 64bit in /usr/bin64, and /usr/bin->/usr/bin64 > >> 2) 32bit in /usrbin32, 64bit in /usr/bin > > > > Nice solution. However, what exactly is the problem that this solves? > > > > Meant /usr/bin32. Anyway, problem is how to install both 64 and 32 bit > versions of your favorite app. Like, mozilla. We x86_64 64bit users often > have to install a 32bit browser so that 32bit plugins will work. Since the i386 packages in x86_64 multilib distributions are simply the ones from the i386 one, the 32bit binaries would have to land into /usr/bin. A solution to what you rpopse would be to have x86_64 binaries in [/usr[/local]]/[s]bin64 and have come before the bin dirs in the PATH. But the multilib policy is to simply use i386 packages when the x86_64 binaries don't work. And within Fedora Core's scope (only open source) firefox/x86_64 does indeed work with all plugins. java and flash don't count since they are not OSS. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From icon at fedoraproject.org Sat Jan 14 22:13:00 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sat, 14 Jan 2006 17:13:00 -0500 Subject: PHP requiring Apache In-Reply-To: <1137269697.2901.6.camel@ender> References: <43C94190.3000906@fedoraproject.org> <1137269697.2901.6.camel@ender> Message-ID: <43C9776C.2030909@fedoraproject.org> ? 14/01/06 03:14 PM, Jesse Keating a ?crit: >> Suggestion: >> So that apache doesn't get installed as dead weight in >> configurations where PHP is used without it, the bits and pieces of >> PHP that actually deal with Apache should be moved to a separate >> sub-package. >> >> Thoughts? (Other than "php must die?") > > Seems reasonable, should be a RFE in bugzilla (; Filed as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177821 Cheers, -- Konstantin Ryabitsev McGill University WSG Montr?al, Qu?bec From fedora at adslpipe.co.uk Sat Jan 14 22:54:13 2006 From: fedora at adslpipe.co.uk (Andy Burns) Date: Sat, 14 Jan 2006 22:54:13 +0000 Subject: suspend/hibernate on desktops Message-ID: <43C98115.6000800@adslpipe.co.uk> I've been playing with the pm-suspend and pm-hibernate on my desktop withe recent kernels (rawhide and davej repo) sometimes I it dies, sometimes it nearly works, sometimes it refuses to sleep but comes straight back to life, I think once it even came back to life after susppending, all good fun :-) Just wondering are the developers particularly interested in getting suspend/resume working on desktops in FC5, or is the prime focus to get it working on "popular" laptops first? Since my test box is intended to end up as a htpc, I'd appreciate anything which helps it be as silent as possible, but I don't want to raise diversions if the focus is elsewhere ... Thoughts? From buildsys at redhat.com Sun Jan 15 08:51:00 2006 From: buildsys at redhat.com (Build System) Date: Sun, 15 Jan 2006 03:51:00 -0500 Subject: rawhide report: 20060115 changes Message-ID: <200601150851.k0F8p0po028788@porkchop.devel.redhat.com> Removed package pup Updated Packages: kernel-2.6.15-1.1854_FC5 ------------------------ pirut-0.9.4-1 ------------- Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.9.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.10.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.8.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires /lib/modules/2.6.15-1.1826.2.10_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.14.i686 requires kernel-smp = 0:2.6.15-1.1826.2.10_FC5 systemtap - 0.5.2-2.i386 requires libdw.so.1(ELFUTILS_0.118) Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs systemtap - 0.5.2-2.ia64 requires libdw.so.1(ELFUTILS_0.118)(64bit) Broken deps for ppc ---------------------------------------------------------- ccs-devel - 1.0.2-3.1.ppc requires ccs = 0:1.0.2-3.1 gulm - 1.0.4-2.FC5.1.ppc requires ccs systemtap - 0.5.2-2.ppc requires libdw.so.1(ELFUTILS_0.118) Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 systemtap - 0.5.2-2.ppc64 requires libdw.so.1(ELFUTILS_0.118)(64bit) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires libdw.so.1(ELFUTILS_0.118) systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires libdw.so.1(ELFUTILS_0.118)(64bit) systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.9.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.10.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.8.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires kernel = 0:2.6.15-1.1826.2.10_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.14.x86_64 requires /lib/modules/2.6.15-1.1826.2.10_FC5 systemtap - 0.5.2-2.x86_64 requires libdw.so.1(ELFUTILS_0.118)(64bit) From mailinglists at erwinrol.com Sun Jan 15 12:19:32 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 15 Jan 2006 13:19:32 +0100 Subject: evolution icons Message-ID: <1137327573.2870.3.camel@xpc.home.erwinrol.com> In evolutions there seem to be some icons missing since yesterday, the default gtk (document with red cross icons) show up, for things like folders in the tree view. - Erwin From mailinglists at erwinrol.com Sun Jan 15 14:26:54 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 15 Jan 2006 15:26:54 +0100 Subject: rawhide report: 20060115 changes In-Reply-To: <200601150851.k0F8p0po028788@porkchop.devel.redhat.com> References: <200601150851.k0F8p0po028788@porkchop.devel.redhat.com> Message-ID: <1137335214.3180.4.camel@xpc.home.erwinrol.com> On Sun, 2006-01-15 at 03:51 -0500, Build System wrote: > kernel-2.6.15-1.1854_FC5 > ------------------------ With this and the previous kernel i get a whole bunch of selinux "errors" Jan 15 14:33:18 xpc kernel: audit(1137331983.110:16): avc: denied { sendto } for scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=association Jan 15 14:33:18 xpc init: Switching to runlevel: 6 Jan 15 14:33:18 xpc kernel: audit(1137331983.414:17): avc: denied { sendto } for scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=association Jan 15 14:33:18 xpc kernel: audit(1137331983.438:18): avc: denied { sendto } for pid=2142 comm="rpc.statd" scontext=system_u:system_r:rpcd_t tcontext=system_u:object_r:unlabeled_t tclass=association which than cause; Jan 15 14:33:18 xpc kernel: portmap: RPC call returned error 1 Jan 15 14:33:18 xpc kernel: RPC: failed to contact portmap (errno -1). Jan 15 14:33:18 xpc kernel: portmap: RPC call returned error 1 when i than reboot i get the following; Jan 15 14:33:20 xpc kernel: Debug: sleeping function called from invalid context at include/linux/rwsem.h:43 Jan 15 14:33:20 xpc kernel: in_atomic():1, irqs_disabled():0 Jan 15 14:33:20 xpc kernel: Jan 15 14:33:20 xpc kernel: Call Trace: {audit_log_exit+366} Jan 15 14:33:20 xpc kernel: {audit_free+272} {__put_task_struct+190} Jan 15 14:33:20 xpc kernel: {__rcu_process_callbacks+297} {rcu_process_callbacks+35} Jan 15 14:33:20 xpc kernel: {tasklet_action+98} {__do_softirq+85} Jan 15 14:33:20 xpc kernel: {call_softirq+30} {do_softirq+44} Jan 15 14:33:20 xpc kernel: {apic_timer_interrupt+132} {getname+30} Jan 15 14:33:20 xpc kernel: {check_poison_obj+48} {getname+30} Jan 15 14:33:20 xpc kernel: {cache_alloc_debugcheck_after+48} Jan 15 14:33:20 xpc kernel: {kmem_cache_alloc+142} {getname+30} Jan 15 14:33:20 xpc kernel: {do_sys_open+17} {tracesys+209} Jan 15 14:33:21 xpc auditd[2162]: The audit daemon is exiting. Jan 15 14:33:21 xpc kernel: audit(1137332001.407:235): audit_pid=0 old=2162 by auid=4294967295 - Erwin From mailinglists at erwinrol.com Sun Jan 15 15:10:33 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 15 Jan 2006 16:10:33 +0100 Subject: evolution crash In-Reply-To: <1137327573.2870.3.camel@xpc.home.erwinrol.com> References: <1137327573.2870.3.camel@xpc.home.erwinrol.com> Message-ID: <1137337833.3667.1.camel@xpc.home.erwinrol.com> On Sun, 2006-01-15 at 13:19 +0100, Erwin Rol wrote: > In evolutions there seem to be some icons missing since yesterday, the > default gtk (document with red cross icons) show up, for things like > folders in the tree view. Evolution crashes when clicking on the "From" sort table-header-button. - Erwin From mailinglists at erwinrol.com Sun Jan 15 15:37:52 2006 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sun, 15 Jan 2006 16:37:52 +0100 Subject: terminal special characters wrong Message-ID: <1137339472.3667.5.camel@xpc.home.erwinrol.com> Since i don't use it much i now noticed that when using menuconfig for a linux kernel build the characters are wrong (see below). This also seems to be the case with other curses programs, any idea what caused it and how to fix it. - Erwin LinuxKernelv2.6.15Configuration ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^^@^@^@^@^@^@^@^@^@^@^@^LinuxKernelConfiguration@^@^@^@^@^@^@^@^@^@^@^@^^@^@ ^@^@ Arrow keys navigate the menu. selects submenus --->. @^^@ Highlighted letters are hotkeys. Pressing includes, excludes, @^^@ modularizes features. Press to exit, for Help, @^^@ for Search. Legend: [*] built-in [ ] excluded module < > @^^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @C@^^maturityleveloptions--->^@^ ^@ @@^@^Generalsetup---> ^@ @@^@^Loadablemodulesupport---> ^@ @@^@^Blocklayer---> ^@ @@^@^Processortypeandfeatures---> ^@ @@^@^Powermanagementoptions---> ^@ @@^@^Busoptions(PCIetc.)---> ^@ @@^@^Executablefileformats/Emulations---> ^@ @@^@^Networking---> ^@ @@^@^DeviceDrivers---> ^@ @^^@^@\(+)^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@