New package crash crash utility for live systems; netdump, diskdump, LKCD or mcore dumpfiles
Updated Packages:
authd-1.3.4-1.fc3 ----------------- * Tue Jul 13 2004 Adrian Havill havill@redhat.com - 1.3.4-1
- retry reading proc with pauses to reduce false negatives - match IPv4 addresses against IPv6 compatibility addresses
balsa-2.2.0-1,FC3,2 ------------------- * Wed Jul 14 2004 John Dennis jdennis@redhat.com 2.2.0-1,FC3,2
- add a 64 bit patch
* Wed Jul 14 2004 John Dennis jdennis@redhat.com 2.2.0-1,FC3,1
- bring up to latest upstream had to change the following from the upstream src rpm: dependency on pspell to aspell build dependency on libesmtp to libesmtp-devel comment out packager rpm tag, RH build system won't accept it
* Sat Jul 26 2003 Misu Moldovan dumol@go.ro
- further split the Red Hat and Mandrake sections - fix Mandrake 9.x dependencies
ethereal-0.10.5-2 ----------------- * Wed Jul 14 2004 Phil Knirsch pknirsch@redhat.com 0.10.5-2
- Applied missing patches from previous version (#120662) - Fixed python module installation (#127614)
gnome-session-2.6.0-7 --------------------- * Wed Jul 14 2004 root markmc@localhost.localdomain - 2.6.0-7
- Add patch to activate vino based on the "remote_access/enabled" preference
kernel-2.6.7-1.488 ------------------ * Wed Jul 14 2004 Arjan van de Ven arjanv@redhat.com
- 2.6.8-rc1-bk3
koffice-1.3.2-2 --------------- * Tue Jul 13 2004 Than Ngo than@redhat.com 4:1.3.2-2
- rebuild
kudzu-1.1.73-1 -------------- * Wed Jul 14 2004 Bill Nottingham notting@redhat.com - 1.1.73-1
- fix ddc probe on ppc (#127827) - make USB probe ignore auxillary interfaces (#79278, bnocera@redhat.com)
netdump-0.6.13-1 ---------------- * Fri Jul 09 2004 Jeff Moyer jmoyer@redhat.com - 0.6.13-1
- More init script fixes. Namely, don't load netdump module if netdumpaddr isn't filled in.
* Thu Jul 08 2004 Jeff Moyer jmoyer@redhat.com - 0.6.12-1
- Add support for 2.6 netdump. - Allow netlog to be configured indepndently from netdump. - Change the server to create only one directory in /var/crash per boot of a system.
* Sun Nov 02 2003 Dave Anderson anderson@redhat.com 0.6.11-3
- rebuild
php-4.3.8-3 ----------- * Wed Jul 14 2004 Joe Orton jorton@redhat.com 4.3.8-3
- update to 4.3.8 - catch some fd > FD_SETSIZE vs select() issues (#125258)
rpmdb-fedora-2-0.20040715 -------------------------
selinux-policy-strict-1.15.5-2 ------------------------------ * Wed Jul 14 2004 Dan Walsh dwalsh@redhat.com 1.15.5-2
- Add device_type create_file_perms to unconfined_t
* Wed Jul 14 2004 Dan Walsh dwalsh@redhat.com 1.15.5-1
- add rpm_t for unconfined_t
selinux-policy-targeted-1.15.5-2 -------------------------------- * Wed Jul 14 2004 Dan Walsh dwalsh@redhat.com 1.15.5-2
- Add device_type create_file_perms to unconfined_t
* Wed Jul 14 2004 Dan Walsh dwalsh@redhat.com 1.15.5-1
- add rpm_t for unconfined_t
* Mon Jul 12 2004 Dan Walsh dwalsh@redhat.com 1.15.4-1
- Break out unlimitedServices in to multiple tunables
system-config-printer-0.6.104-1 ------------------------------- * Wed Jul 14 2004 Tim Waugh twaugh@redhat.com 0.6.104-1
- 0.6.104: - Fixed chkconfig invocation. - New po files. - Use GTK methods that are not deprecated. - Print a message about unmatched USB model/mfr strings.
udev-029-4 ---------- * Wed Jul 14 2004 Harald Hoyer harald@redhat.com - 029-4
- added udevstart.static
* Wed Jul 14 2004 Harald Hoyer harald@redhat.com - 029-3
- put /etc/sysconfig/udev in /etc/udev/udev.conf and removed it - made only udev.static static - make our defaults the default values - removed /udev
w3m-el-1.4.2-1 -------------- * Thu Jul 15 2004 Akira TAGOH tagoh@redhat.com 1.4.2-1
- New upstream release.
On Thu, 2004-07-15 at 13:44, Build System wrote:
balsa-2.2.0-1,FC3,2
- Wed Jul 14 2004 John Dennis jdennis@redhat.com 2.2.0-1,FC3,2
- add a 64 bit patch
- Wed Jul 14 2004 John Dennis jdennis@redhat.com 2.2.0-1,FC3,1
- bring up to latest upstream had to change the following from the upstream src rpm: dependency on pspell to aspell build dependency on libesmtp to libesmtp-devel comment out packager rpm tag, RH build system won't accept it
- Sat Jul 26 2003 Misu Moldovan dumol@go.ro
- further split the Red Hat and Mandrake sections
- fix Mandrake 9.x dependencies
Hum.. if we're *talking* about removing ethereal then I think balsa's removal from core should at least be discussed: I can't recall the last time I've seen anybody even mention using Balsa. Of course it's possible a) I haven't seen balsa-related discussions because I'm not looking for them b) it's so perfect the users are too happy to complain ... but somehow I doubt both of those. We got plenty enough email-clients in core already, I think balsa would be best moved to Extras.
- Panu -
On Thu, 2004-07-15 at 10:07, Panu Matilainen wrote:
Hum.. if we're *talking* about removing ethereal then I think balsa's removal from core should at least be discussed: I can't recall the last time I've seen anybody even mention using Balsa. Of course it's possible a) I haven't seen balsa-related discussions because I'm not looking for them b) it's so perfect the users are too happy to complain ... but somehow I doubt both of those. We got plenty enough email-clients in core already, I think balsa would be best moved to Extras.
Yeah, agreed.
Havoc
Havoc Pennington (hp@redhat.com) said:
Hum.. if we're *talking* about removing ethereal then I think balsa's removal from core should at least be discussed: I can't recall the last time I've seen anybody even mention using Balsa. Of course it's possible a) I haven't seen balsa-related discussions because I'm not looking for them b) it's so perfect the users are too happy to complain ... but somehow I doubt both of those. We got plenty enough email-clients in core already, I think balsa would be best moved to Extras.
Yeah, agreed.
IMO, the only reason balsa isn't in extras is because we haven't fully merged Extras yet. (Same goes for sylpheed, actually.)
Of course, we can just move it to fedora.us anyway; I wouldn't be against that.
Bill
On 15/07/2004 15:07 Panu Matilainen wrote:
Hum.. if we're *talking* about removing ethereal then I think balsa's removal from core should at least be discussed: I can't recall the last time I've seen anybody even mention using Balsa. Of course it's possible a) I haven't seen balsa-related discussions because I'm not looking for them b) it's so perfect the users are too happy to complain ... but somehow I doubt both of those. We got plenty enough email-clients in core already, I think balsa would be best moved to Extras.
I strongly disagree. If you're going to kick out a GUI MUA, I suggest getting rid of Outlook^H^H^H^H^H^HEvolution. Bloated crapware IMO.
Paul Thomas wrote:
On 15/07/2004 15:07 Panu Matilainen wrote:
Hum.. if we're *talking* about removing ethereal then I think balsa's removal from core should at least be discussed: I can't recall the last time I've seen anybody even mention using Balsa. Of course it's possible a) I haven't seen balsa-related discussions because I'm not looking for them b) it's so perfect the users are too happy to complain ... but somehow I doubt both of those. We got plenty enough email-clients in core already, I think balsa would be best moved to Extras.
I strongly disagree. If you're going to kick out a GUI MUA, I suggest getting rid of Outlook^H^H^H^H^H^HEvolution. Bloated crapware IMO.
Yeah, but I like evo's calendar:)
my $0.02, Mark
On 15/07/2004 15:51 Mark Johnson wrote:
[snip] Yeah, but I like evo's calendar:)
Why should a MUA have a calendar though? And why do they thing I'd be interested in the weather in the USA? Evo is a total joke. Get rid of it.
On 15/07/2004 16:23 seth vidal wrote:
Why should a MUA have a calendar though? And why do they thing I'd be interested in the weather in the USA? Evo is a total joke. Get rid of
it.
wow, glad you're not hostile or flaming.
No. I'll save that for the Xinian PHBs if I ever come across any of them ;)
On Thu, 2004-07-15 at 12:13, Paul Thomas wrote:
On 15/07/2004 16:23 seth vidal wrote:
Why should a MUA have a calendar though? And why do they thing I'd be interested in the weather in the USA? Evo is a total joke. Get rid of
it.
wow, glad you're not hostile or flaming.
No. I'll save that for the Xinian PHBs if I ever come across any of them ;)
it'd be a shame to do that. I know some of the PHB's involved(or formerly involved) in the evo team and they're good folks.
-sv
seth vidal wrote:
On Thu, 2004-07-15 at 12:13, Paul Thomas wrote:
On 15/07/2004 16:23 seth vidal wrote:
Why should a MUA have a calendar though? And why do they thing I'd be interested in the weather in the USA? Evo is a total joke. Get rid of
it.
wow, glad you're not hostile or flaming.
No. I'll save that for the Xinian PHBs if I ever come across any of them ;)
it'd be a shame to do that. I know some of the PHB's involved(or formerly involved) in the evo team and they're good folks.
Ditto seth's remark, FWIW.
Cheers, Mark
On Thu, 2004-07-15 at 16:20, Paul Thomas wrote:
On 15/07/2004 15:51 Mark Johnson wrote:
[snip] Yeah, but I like evo's calendar:)
Why should a MUA have a calendar though? And why do they thing I'd be interested in the weather in the USA? Evo is a total joke. Get rid of it.
I guess you didn't think of the idea that it can be configured to use UK weather - from one of several sites. Alternatively you can just stick a raining icon there - just as accurate for the UK and saves you the bandwidth for queries.
Having had a week of getting stupid queries I am quite relieved to see that the USA has lost the monopoly on stupidity. Shame it ends up being the UK blindly following on though. Theres obviously a political point there....
Nigel.
On 15/07/2004 16:36 Nigel Metheringham wrote:
On Thu, 2004-07-15 at 16:20, Paul Thomas wrote:
On 15/07/2004 15:51 Mark Johnson wrote:
[snip] Yeah, but I like evo's calendar:)
Why should a MUA have a calendar though? And why do they thing I'd be interested in the weather in the USA? Evo is a total joke. Get rid of
it.
I guess you didn't think of the idea that it can be configured to use UK weather - from one of several sites.
So what? The point is why is such a function in an MUA?
Alternatively you can just stick a raining icon there - just as accurate for the UK and saves you the bandwidth for queries.
Or I could just look out of the window...
Having had a week of getting stupid queries I am quite relieved to see that the USA has lost the monopoly on stupidity. Shame it ends up being the UK blindly following on though. Theres obviously a political point there....
So anyone who doesn't agree with you is stupid eh?
Hi,
Guys, this is a development list; flames and noise aren't really welcome. I'm not assigning blame, just everyone please don't continue.
For choosing default desktop apps, there's a writeup of some factors here: http://fedora.redhat.com/projects/desktop/defaults.html
Havoc
The weather feature you hate so much along with all of the Summary section have been removed in Evolution 2.0 which is scheduled for FC3, you can check this using the version in Development.
- David
On tor, 2004-07-15 at 19:57 +0100, Paul Thomas wrote:
On 15/07/2004 16:36 Nigel Metheringham wrote:
On Thu, 2004-07-15 at 16:20, Paul Thomas wrote:
On 15/07/2004 15:51 Mark Johnson wrote:
[snip] Yeah, but I like evo's calendar:)
Why should a MUA have a calendar though? And why do they thing I'd be interested in the weather in the USA? Evo is a total joke. Get rid of
it.
I guess you didn't think of the idea that it can be configured to use UK weather - from one of several sites.
So what? The point is why is such a function in an MUA?
Alternatively you can just stick a raining icon there - just as accurate for the UK and saves you the bandwidth for queries.
Or I could just look out of the window...
Having had a week of getting stupid queries I am quite relieved to see that the USA has lost the monopoly on stupidity. Shame it ends up being the UK blindly following on though. Theres obviously a political point there....
So anyone who doesn't agree with you is stupid eh?
-- Paul Thomas +------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+
Hi,
please don't hijack the discussion to make pet peeve rants. People have said they'd want to remove balsa, so stick to the topic and give reasons to not remove balsa. Yes, I know the topic is "removal of any package", but the inflammatory way you ask for removal of evo does the discussion of what packages to remove no good.
[snip] Yeah, but I like evo's calendar:)
Why should a MUA have a calendar though? And why do they thing I'd be interested in the weather in the USA? Evo is a total joke. Get rid of
it.
I guess you didn't think of the idea that it can be configured to use UK weather - from one of several sites.
So what? The point is why is such a function in an MUA?
Because it's not a MUA just because you say so ? From the package description: Evolution is the GNOME collection of personal information management (PIM) tools.
Anyway, a whole lot of people use evolution and are very happy with it. In this thread someone doubted whether the same applies for balsa. That's something worth discussing.
+------------------------------+---------------------------------------------+ | Thomas Micro Systems Limited | Software Solutions for Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +------------------------------+---------------------------------------------+
What email client do you consult to businesses, out of curiosity ?
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> And redemption will pour and crashes to the floor And a million cold thoughts won't stop you feeling warm Because the love that you bring conquers all these things <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
Anyway, a whole lot of people use evolution and are very happy with it. In this thread someone doubted whether the same applies for balsa. That's something worth discussing.
I think balsa is a nice, simple MUA and I generally recommend it for users that I install Linux for. I'm not a fan of the current Outlook/Evolution approach. Having said that, balsa is a great candidate for Fedora Extras. If people want to reduce the size of Fedora Core (this opinion seems to be pretty much unanimous) then we need to start making compromises like this.
-- Mike
On Fri, 2004-07-16 at 09:22 -0500, W. Michael Petullo wrote:
I think balsa is a nice, simple MUA and I generally recommend it for users that I install Linux for. I'm not a fan of the current Outlook/Evolution approach. Having said that, balsa is a great candidate for Fedora Extras. If people want to reduce the size of Fedora Core (this opinion seems to be pretty much unanimous) then we need to start making compromises like this.
The problem with most MUAs, is that they don't support advanced features, like SASL authentication (CRAM-MD5, Kerberos, X.509, etc) or disconnected (offline) operation when using IMAP. That's one of the reasons I keep using Evolution, since I *need* Kerberos authentication support to access my IMAP mailbox. AFAIK, only Pine does also support Kerberos authentication via SASL.
On Fri, 2004-07-16 at 17:02 +0200, Felipe Alfaro Solana wrote:
On Fri, 2004-07-16 at 09:22 -0500, W. Michael Petullo wrote:
I think balsa is a nice, simple MUA and I generally recommend it for users that I install Linux for. I'm not a fan of the current Outlook/Evolution approach. Having said that, balsa is a great candidate for Fedora Extras. If people want to reduce the size of Fedora Core (this opinion seems to be pretty much unanimous) then we need to start making compromises like this.
The problem with most MUAs, is that they don't support advanced features, like SASL authentication (CRAM-MD5, Kerberos, X.509, etc) or disconnected (offline) operation when using IMAP. That's one of the reasons I keep using Evolution, since I *need* Kerberos authentication support to access my IMAP mailbox. AFAIK, only Pine does also support Kerberos authentication via SASL.
Mutt supports it too, FWIW.
On 07/16/2004 05:02:54 PM, Felipe Alfaro Solana wrote:
On Fri, 2004-07-16 at 09:22 -0500, W. Michael Petullo wrote:
I think balsa is a nice, simple MUA and I generally recommend it
for users
that I install Linux for. I'm not a fan of the current
Outlook/Evolution
approach. Having said that, balsa is a great candidate for Fedora
Extras.
If people want to reduce the size of Fedora Core (this opinion
seems to
be pretty much unanimous) then we need to start making compromises
like
this.
The problem with most MUAs, is that they don't support advanced features, like SASL authentication (CRAM-MD5, Kerberos, X.509, etc) or disconnected (offline) operation when using IMAP. That's one of the reasons I keep using Evolution, since I *need* Kerberos authentication support to access my IMAP mailbox. AFAIK, only Pine does also support Kerberos authentication via SASL.
balsa-2.2.x does support Kerberos authentication (AUTH=GSSAPI). It supports AUTH=CRAM-MD5 as well. It is a lightweight client and the offline operation is not there but it can well open mailboxes containing 10000+ messages over a dialup link (the slow part is GtkTreeView, it has problems rendering that many rows). Try that with other heavy weight MUAs without having a cache preloaded.
Pawel
Pawel Salek wrote:
On 07/16/2004 05:02:54 PM, Felipe Alfaro Solana wrote:
On Fri, 2004-07-16 at 09:22 -0500, W. Michael Petullo wrote:
I think balsa is a nice, simple MUA and I generally recommend it for
users
that I install Linux for. I'm not a fan of the current
Outlook/Evolution
approach. Having said that, balsa is a great candidate for Fedora
Extras.
If people want to reduce the size of Fedora Core (this opinion
seems to
be pretty much unanimous) then we need to start making compromises
like
this.
The problem with most MUAs, is that they don't support advanced features, like SASL authentication (CRAM-MD5, Kerberos, X.509, etc) or disconnected (offline) operation when using IMAP. That's one of the reasons I keep using Evolution, since I *need* Kerberos authentication support to access my IMAP mailbox. AFAIK, only Pine does also support Kerberos authentication via SASL.
balsa-2.2.x does support Kerberos authentication (AUTH=GSSAPI). It supports AUTH=CRAM-MD5 as well. It is a lightweight client and the offline operation is not there but it can well open mailboxes containing 10000+ messages over a dialup link (the slow part is GtkTreeView, it has problems rendering that many rows). Try that with other heavy weight MUAs without having a cache preloaded.
Pawel
I tried out Balsa for a short time and thought that is was a decent program. I did notice that the size that you made certain items. (subject, date, sender, etc:) were defaulted to the original size (not the sizes that I preferred) on restarting application. Another thing that was a distraction was the deleted items still showing , even after messages were deleted. I viewed it as a mini-evolution mailer. A mailer that is worthy of inclusion, but not as a substitute for another program just yet.
Jim
Paul Thomas wrote:
On 15/07/2004 15:07 Panu Matilainen wrote:
Hum.. if we're *talking* about removing ethereal then I think balsa's removal from core should at least be discussed: I can't recall the last time I've seen anybody even mention using Balsa.
I strongly disagree. If you're going to kick out a GUI MUA, I suggest getting rid of Outlook^H^H^H^H^H^HEvolution. Bloated crapware IMO.
I saw the red glow of this flame mail from the outer reaches of my inbox. Evolution is a necessary evil until Thunderbird and Sunbird mature a little bit. At that point i agree to the replacement of Evolution by the mozilla "modular suite". -- Michael Favia Insites Incorporated
On Thu, 2004-07-15 at 11:01, Garbage wrote:
I saw the red glow of this flame mail from the outer reaches of my inbox. Evolution is a necessary evil until Thunderbird and Sunbird mature a little bit. At that point i agree to the replacement of Evolution by the mozilla "modular suite". --
I disagree. Now that Ximian Exchange Connector is released under the GPL, Evolution is THE killer app for Linux on the desktop in many environments.
On Thu, Jul 15, 2004 at 11:32:47AM -0400, Aaron Bennett wrote:
On Thu, 2004-07-15 at 11:01, Garbage wrote:
I saw the red glow of this flame mail from the outer reaches of my inbox. Evolution is a necessary evil until Thunderbird and Sunbird mature a little bit. At that point i agree to the replacement of Evolution by the mozilla "modular suite".
I disagree. Now that Ximian Exchange Connector is released under the GPL, Evolution is THE killer app for Linux on the desktop in many environments.
"Now that Ximian Exchange Connector is released under the GPL," why not add a Calendar feature to the mozilla suite of tools, and re-use it the Ximian Exchange Connector code as a "Mozilla Exchange Connector"?
mark
On 15/07/2004 16:01 Garbage wrote:
I saw the red glow of this flame mail from the outer reaches of my inbox. Evolution is a necessary evil until Thunderbird and Sunbird mature a little bit. At that point i agree to the replacement of Evolution by the mozilla "modular suite".
I don't see why it's necessary. I think it's promotion as the preferred GNOME MUA is more likely to be political than technical. I haven't looked at any of the latest stuff from Mozilla so I don't know how it differs from the old Mozilla Mail program.
Paul Thomas wrote:
On 15/07/2004 16:01 Garbage wrote:
I saw the red glow of this flame mail from the outer reaches of my inbox. Evolution is a necessary evil until Thunderbird and Sunbird mature a little bit. At that point i agree to the replacement of Evolution by the mozilla "modular suite".
I don't see why it's necessary. I think it's promotion as the preferred GNOME MUA is more likely to be political than technical. I haven't looked at any of the latest stuff from Mozilla so I don't know how it differs from the old Mozilla Mail program.
I have found that the newest developments coming out of mozilla are much more intelligently designed and slimmed down for mass consumption on any system. the most recent Thunderbird and Firefox represent the agility and compactness that i am refering to. if you havent looked lately you will find an entirely different beast (i disliked and didnt use original mozilla suite for the last 5 years unless i had to and then i switched back sometime last year). Best Wishes, Michael Favia
Paul Thomas wrote:
On 15/07/2004 15:07 Panu Matilainen wrote:
Hum.. if we're *talking* about removing ethereal then I think balsa's removal from core should at least be discussed: I can't recall the last time I've seen anybody even mention using Balsa. Of course it's possible a) I haven't seen balsa-related discussions because I'm not looking for them b) it's so perfect the users are too happy to complain ... but somehow I doubt both of those. We got plenty enough email-clients in core already, I think balsa would be best moved to Extras.
I strongly disagree. If you're going to kick out a GUI MUA, I suggest getting rid of Outlook^H^H^H^H^H^HEvolution. Bloated crapware IMO.
I don't use either balsa or evolution. They seem to conflict with each other though.
Trying to Upgrade Evolution, Evolution-data-server and gtkhtml3. I get the below popup using up2date.
Unresolvable chain of dependencies: balsa 2.2.0-1,FC3,2 requires libgtkhtml-3.1.so.10
I like a variety choices though. Mozilla-mail is my choice.
Jim
On Thu, 2004-07-15 at 13:44, Build System wrote:
balsa-2.2.0-1,FC3,2
- Wed Jul 14 2004 John Dennis jdennis@redhat.com 2.2.0-1,FC3,2
- add a 64 bit patch
- Wed Jul 14 2004 John Dennis jdennis@redhat.com 2.2.0-1,FC3,1
- bring up to latest upstream had to change the following from the upstream src rpm: dependency on pspell to aspell build dependency on libesmtp to libesmtp-devel comment out packager rpm tag, RH build system won't accept it
- Sat Jul 26 2003 Misu Moldovan dumol@go.ro
- further split the Red Hat and Mandrake sections
- fix Mandrake 9.x dependencies
Hum.. if we're *talking* about removing ethereal then I think balsa's removal from core should at least be discussed: I can't recall the last time I've seen anybody even mention using Balsa. Of course it's possible a) I haven't seen balsa-related discussions because I'm not looking for them b) it's so perfect the users are too happy to complain ... but somehow I doubt both of those. We got plenty enough email-clients in core already, I think balsa would be best moved to Extras.
- Panu -
I would say the same of licq, that we should move these less popular clients into extras.
Warren
Maybe it's about time we had a FC repo cleanup day, everyone join IRC and we debate what to ship to Extras to avoid duplication.
- David
On tor, 2004-07-15 at 12:09 -1000, Warren Togami wrote:
On Thu, 2004-07-15 at 13:44, Build System wrote:
balsa-2.2.0-1,FC3,2
- Wed Jul 14 2004 John Dennis jdennis@redhat.com 2.2.0-1,FC3,2
- add a 64 bit patch
- Wed Jul 14 2004 John Dennis jdennis@redhat.com 2.2.0-1,FC3,1
- bring up to latest upstream had to change the following from the upstream src rpm: dependency on pspell to aspell build dependency on libesmtp to libesmtp-devel comment out packager rpm tag, RH build system won't accept it
- Sat Jul 26 2003 Misu Moldovan dumol@go.ro
- further split the Red Hat and Mandrake sections
- fix Mandrake 9.x dependencies
Hum.. if we're *talking* about removing ethereal then I think balsa's removal from core should at least be discussed: I can't recall the last time I've seen anybody even mention using Balsa. Of course it's possible a) I haven't seen balsa-related discussions because I'm not looking for them b) it's so perfect the users are too happy to complain ... but somehow I doubt both of those. We got plenty enough email-clients in core already, I think balsa would be best moved to Extras.
- Panu -
I would say the same of licq, that we should move these less popular clients into extras.
Warren
Once upon a time, David Nielsen dnielsen@breakmygentoo.net said:
Maybe it's about time we had a FC repo cleanup day, everyone join IRC and we debate what to ship to Extras to avoid duplication.
I'd like to see a real Fedora Extras first. It would be good to have ISOs available and anaconda be able to use additional ISOs during install. I think this should be a goal because otherwise upgrades don't go so well. For example, if I have xmms from Fedora Core and xmms-sid from Fedora Extras (currently in fedora.us), when I upgrade using Fedora Core CDs, xmms won't get upgraded (because of the dependency).
On Thu, Jul 15, 2004 at 07:47:53PM -0500, Chris Adams wrote:
I'd like to see a real Fedora Extras first. It would be good to have ISOs available and anaconda be able to use additional ISOs during install. I think this should be a goal because otherwise upgrades don't go so well. For example, if I have xmms from Fedora Core and xmms-sid from Fedora Extras (currently in fedora.us), when I upgrade using Fedora Core CDs, xmms won't get upgraded (because of the dependency).
FWIW, the way that Red Hat Enterprise Linux 3 handles Extras (closed-source stuff in that case) is to have the option of installing from the Extras CD (or Documentation CD's for that matter) in firstboot. In fact, the generic button for installing more packages from another CD is also present in firstboot in Fedora Core 2 and fc-devel (although the Extras and Documentation buttons aren't).
I can see how it might be better to handle Extras in anaconda for the sake of cleaner upgrades, but perhaps the RHEL method is still worth mentioning in this thread...
-Barry K. Nathan barryn@pobox.com
On Thu, Jul 15, 2004 at 05:32:50PM -0700, Barry K. Nathan wrote:
FWIW, the way that Red Hat Enterprise Linux 3 handles Extras (closed-source stuff in that case) is to have the option of installing from the Extras CD (or Documentation CD's for that matter) in firstboot. In fact, the generic button for installing more packages from another CD is also present in firstboot in Fedora Core 2 and fc-devel (although the Extras and Documentation buttons aren't).
That would make it hard to integrate those packages into a kickstart upgrade/install.
I can see how it might be better to handle Extras in anaconda for the sake of cleaner upgrades, but perhaps the RHEL method is still worth mentioning in this thread...
I'll just point to what I said on this subject before. :-)
http://www.redhat.com/archives/fedora-devel-list/2004-June/msg00267.html
Steve
On 07/15/2004 08:47:53 PM, Chris Adams wrote:
Once upon a time, David Nielsen dnielsen@breakmygentoo.net said:
Maybe it's about time we had a FC repo cleanup day, everyone join IRC and we debate what to ship to Extras to avoid duplication.
I'd like to see a real Fedora Extras first. It would be good to have ISOs available and anaconda be able to use additional ISOs during install. I think this should be a goal because otherwise upgrades don't go so well. For example, if I have xmms from Fedora Core and xmms-sid from Fedora Extras (currently in fedora.us), when I upgrade using Fedora Core CDs, xmms won't get upgraded (because of the dependency).
I'd like to _strongly_ second this motion!
Regards, Willem Riede.
So should I write up a formal proposal for the list so it draws attention or will this do for now?
Anyways we should hold this session very soon, so we can have a clean test2 release.
- David
On lør, 2004-07-17 at 14:58 +0000, Willem Riede wrote:
On 07/15/2004 08:47:53 PM, Chris Adams wrote:
Once upon a time, David Nielsen dnielsen@breakmygentoo.net said:
Maybe it's about time we had a FC repo cleanup day, everyone join IRC and we debate what to ship to Extras to avoid duplication.
I'd like to see a real Fedora Extras first. It would be good to have ISOs available and anaconda be able to use additional ISOs during install. I think this should be a goal because otherwise upgrades don't go so well. For example, if I have xmms from Fedora Core and xmms-sid from Fedora Extras (currently in fedora.us), when I upgrade using Fedora Core CDs, xmms won't get upgraded (because of the dependency).
I'd like to _strongly_ second this motion!
Regards, Willem Riede.
On Thu, 2004-07-15 at 06:44 -0400, Build System wrote:
kernel-2.6.7-1.488
- Wed Jul 14 2004 Arjan van de Ven arjanv@redhat.com
- 2.6.8-rc1-bk3
Hi,
Booting with -1.486 left me without usb:
[root@roque root]# rpm -ql kernel-2.6.7-1.486 | grep uhci /lib/modules/2.6.7-1.486/build/include/config/usb/uhci /lib/modules/2.6.7-1.486/build/include/config/usb/uhci/hcd.h
[root@roque root]# rpm -ql kernel-2.6.7-1.486 | grep ehci /lib/modules/2.6.7-1.486/build/include/config/usb/ehci /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/hcd.h /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root/hub /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root/hub/tt.h /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/split /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/split/iso.h
And the init scripts complained about not findinf the correct modules.
Is -1.488 any better, did something go wrong or did something change dramatically?
Anyway, back to -1.476, and hping the mirrors catch up soon enough.
Hugs, Rui
Rui Miguel Seabra wrote:
On Thu, 2004-07-15 at 06:44 -0400, Build System wrote:
kernel-2.6.7-1.488
- Wed Jul 14 2004 Arjan van de Ven arjanv@redhat.com
- 2.6.8-rc1-bk3
Hi,
Booting with -1.486 left me without usb:
[root@roque root]# rpm -ql kernel-2.6.7-1.486 | grep uhci /lib/modules/2.6.7-1.486/build/include/config/usb/uhci /lib/modules/2.6.7-1.486/build/include/config/usb/uhci/hcd.h
[root@roque root]# rpm -ql kernel-2.6.7-1.486 | grep ehci /lib/modules/2.6.7-1.486/build/include/config/usb/ehci /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/hcd.h /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root/hub /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/root/hub/tt.h /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/split /lib/modules/2.6.7-1.486/build/include/config/usb/ehci/split/iso.h
And the init scripts complained about not findinf the correct modules.
Is -1.488 any better, did something go wrong or did something change dramatically?
Anyway, back to -1.476, and hping the mirrors catch up soon enough.
Hugs, Rui
seems to be compiled in... no more module..
On Thu, 2004-07-15 at 16:37 +0200, Harald Hoyer wrote:
seems to be compiled in... no more module..
What? And when something strange happens, what am I left to do, reboot? :)
Anyway, being a module is a Good Thing, by default, but I'm curious, why make it built in?
Rui
ps: don't forget to update initscripts...
Rui Miguel Seabra wrote:
On Thu, 2004-07-15 at 16:37 +0200, Harald Hoyer wrote:
seems to be compiled in... no more module..
What? And when something strange happens, what am I left to do, reboot? :)
Anyway, being a module is a Good Thing, by default, but I'm curious, why make it built in?
Don't forget module removal "doesn't work" in 2.6...
On Thu, Jul 15, 2004 at 09:44:28PM -0700, Mike Fedyk wrote:
Don't forget module removal "doesn't work" in 2.6...
Ummm... huh? In my testing it works just fine! Do you have a specific case where it's not working?
(Perhaps module removal wasn't working at some point earlier in 2.6.x history, but it seems to work now!)
-Barry K. Nathan barryn@pobox.com
On Fri, 2004-07-16 at 08:21, Barry K. Nathan wrote:
On Thu, Jul 15, 2004 at 09:44:28PM -0700, Mike Fedyk wrote:
Don't forget module removal "doesn't work" in 2.6...
Ummm... huh? In my testing it works just fine! Do you have a specific case where it's not working?
it's chockfull of races still
(Perhaps module removal wasn't working at some point earlier in 2.6.x history, but it seems to work now!)
I strongly discourage any module removal without good reason; and there are very few such good reasons, the only reason I can think of is driver bugs.
On Fri, Jul 16, 2004 at 09:35:52AM +0200, Arjan van de Ven wrote:
it's chockfull of races still
Most drivers now days are refcounting and well behaved
I strongly discourage any module removal without good reason; and there are very few such good reasons, the only reason I can think of is driver bugs.
and USB and PCMCIA.... (although PCMCIA IDE has bugs still)
On Fri, Jul 16, 2004 at 04:50:45AM -0400, Alan Cox wrote:
On Fri, Jul 16, 2004 at 09:35:52AM +0200, Arjan van de Ven wrote:
it's chockfull of races still
Most drivers now days are refcounting and well behaved
well... and then there is sysfs.
I strongly discourage any module removal without good reason; and there are very few such good reasons, the only reason I can think of is driver bugs.
and USB and PCMCIA.... (although PCMCIA IDE has bugs still)
how so? the 2.6 driver model is that drivers remain loaded and just get reactivated if the device comes back....
On Fri, Jul 16, 2004 at 10:52:38AM +0200, Arjan van de Ven wrote:
and USB and PCMCIA.... (although PCMCIA IDE has bugs still)
how so? the 2.6 driver model is that drivers remain loaded and just get reactivated if the device comes back....
Because many of the drivers use a lot of memory so if you are regularly switching you can lose as much memory to the kernel accumulating modules as you do to stuff like overuse of inlines
On Fri, 16 Jul 2004 10:52:38 +0200 Arjan van de Ven arjanv@redhat.com wrote:
On Fri, Jul 16, 2004 at 04:50:45AM -0400, Alan Cox wrote:
On Fri, Jul 16, 2004 at 09:35:52AM +0200, Arjan van de Ven wrote:
it's chockfull of races still
Most drivers now days are refcounting and well behaved
well... and then there is sysfs.
I strongly discourage any module removal without good reason; and there are very few such good reasons, the only reason I can think of is driver bugs.
and USB and PCMCIA.... (although PCMCIA IDE has bugs still)
how so? the 2.6 driver model is that drivers remain loaded and just get reactivated if the device comes back....
I get oopses very easily when removing a CF card in a PCMCIA adapter (also with latest FC2 kernel). And a machine crash after some time if I remember correctly.
This makes accessing CF basically useless/impossible with FC2.
Thought this was well known or should I add it to bugzilla ?
r.
On Fri, Jul 16, 2004 at 12:57:00PM +0200, Rob van Nieuwkerk wrote:
I get oopses very easily when removing a CF card in a PCMCIA adapter (also with latest FC2 kernel). And a machine crash after some time if I remember correctly.
This makes accessing CF basically useless/impossible with FC2.
Thought this was well known or should I add it to bugzilla ?
Someone else already filed this as bug 127432.
However, all of my attempts to reproduce this on my Toshiba Portege 3500 have failed (i.e. I have no oopses or crashes). However, I'm running FC-devel kernels (which are newer than the latest FC2 kernel), so that might be why.
-Barry K. Nathan barryn@pobox.com
Alan Cox wrote:
On Fri, Jul 16, 2004 at 09:35:52AM +0200, Arjan van de Ven wrote:
it's chockfull of races still
Most drivers now days are refcounting and well behaved
Run multiple instance of the following shell script concurrently:
#!/bin/bash modprobe SOMETHING modprobe -r SOMETHING exec $0
Simultaneously probe something viewable from userspace from that module, like in /proc (note that in most cases this is possible as non-root)
#!/bin/bash cat /proc/SOMETHING exec $0
When testing this around 2.6.4 many drivers blew up spectacularly with kernel panics when doing the first script alone, while others either paniced or eventually got stuck with a huge refcount due to the second script. Some of these were races and fixed since then, but there are undoubtedly many remaining now. Other means of triggering races during unloading scares me, because each test case would need to be designed for each specific module.
Warren Togami wtogami@redhat.com
On Fri, 16 Jul 2004 17:35, Arjan van de Ven arjanv@redhat.com wrote:
(Perhaps module removal wasn't working at some point earlier in 2.6.x history, but it seems to work now!)
I strongly discourage any module removal without good reason; and there are very few such good reasons, the only reason I can think of is driver bugs.
What about PCMCIA drivers?
On Fri, Jul 16, 2004 at 06:52:51PM +1000, Russell Coker wrote:
I strongly discourage any module removal without good reason; and there are very few such good reasons, the only reason I can think of is driver bugs.
What about PCMCIA drivers?
those should remain loaded until the hw comes back