.649 and .667 kernels and random lockups
by seth vidal
Hi Everyone,
I've upgraded two machines to fc3rc5(ish) and then upgraded again to
latest rawhide. I've been running the .649 and .667 kernels on these two
systems. One is a dell dimension 2400 - p4 2.8ghz the other is an ibm
x23 thinkpad - p3-866mhz. Both of them will lockup if they sit idle for
a while. It's a hard lock up, I can't free them of it and I have no idea
what causes it. Is anyone else seeing this, too?
Thanks
-sv
19 years, 5 months
NetworkManager and ndiswrapper
by Thomas J. Baker
Can NM work with ndiswrapper? It doesn't seem to see the wireless wlan0
device at all.
It doesn't seem like something I can bugzilla since ndiswrapper isn't
supported. The sad thing is that it seems like ndiswrapper does a better
job than even the latest 0.15rc2 orinoco drivers as far as providing the
things NM needs to work well.
Thanks,
tjb
--
=======================================================================
| Thomas Baker email: tjb(a)unh.edu |
| Systems Programmer |
| Research Computing Center voice: (603) 862-4490 |
| University of New Hampshire fax: (603) 862-1761 |
| 332 Morse Hall |
| Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb |
=======================================================================
19 years, 5 months
Re: FC4 schedule (was Re: gnome 2.9)
by Ron Yorston
Arjan van de Ven <arjan(a)fenrus.demon.nl> wrote:
>On Wed, 2004-11-03 at 11:44 -0500, Havoc Pennington wrote:
>> Do we have an FC4 schedule yet? FC isn't necessarily 6 months, people
>> could decide to do shorter.
>
>yeah I can see the point of doing a short cycle for FC4, once in a while
>it's good to do a "mostly bugfixes" release to get basic quality
>higher....
>
>and another great feature to get out early will be the new GCC buffer
>overflow checking features.
>
>Sounds like Late January/ early February would be a nice date for a
>followup release....
Especially if you want people to skip FC3. Why bother with it when
there'll be another, better one along in a moment?
Ron
19 years, 5 months
rawhide report: 20041104 changes
by Build System
Updated Packages:
gtk2-2.4.13-9
-------------
* Wed Nov 03 2004 Matthias Clasen <mclasen(a)redhat.com> - 2.4.13-9
- Fix an oversight in the previous fix, really
fix the crash. (#137922)
rpmdb-fedora-3-0.20041104
-------------------------
setarch-1.6-1
-------------
* Wed Nov 03 2004 Elliot Lee <sopwith(a)redhat.com> 1.6-1
- More properly interpret the return value of SYS_personality
udev-039-8.FC3
--------------
* Wed Nov 03 2004 Jeremy Katz <katzj(a)redhat.com> - 039-8.FC3
- recreate lvm device nodes if needed in the trigger (#137807)
* Wed Nov 03 2004 Harald Hoyer <harald(a)redhat.com> - 039-6.FC3.2
- replace udev.conf by default
- LANG=C for fgrep in start_udev; turn grep into fgrep
19 years, 5 months
Re: gnome 2.9
by Alan Milligan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
|
| If this is am open discussion about the FC4 schedule. I would
| personally prefer to see a SLOW release cycle so the non-technical
| issues, the community facing policy/organizational issues can finally
| get some needed high priority allocation from inside the fenceline.
|
Definitely. There is much that needs to be formalised here.
I for one am very disappointed that I have zero control pushing my own
agenda within Fedora. I have four outstanding bugs and enhancements
with patches (135657, 135659, 135660, 120635) which are completely at
the whim RH as to when they may apply them, if ever.
| In terms of what is important in the long term health of fedora as a
| community project and not just a collection of code.. time needs to be
| made by the primaries inside Red Hat to deal the issues of how
| community is actually going to be invited and encouraged to be
| invovled beyond upstream component developers. Pushing a quick fc4
| schedule is NOT going to make it easier to deal with any community
| contributor/leadership issues... real or imagined, outstanding or
| looming.
|
Indeed. A quick push just means there's even less time to lobby for
changes that have already been deferred because you were all too busy
getting out FC3.
We already see that existing RH resources are struggling to be reactive
to the situation. If you cannot open this project up along the lines of
other large open projects, whereby I can influence the final product,
then I will seriously consider participating elsewhere.
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBiaQnCfroLk4EZpkRAkDVAJ4uhkh8jg0kfvuliTqX6A9PPe29fgCfa1rA
Eb3F0X9XG5vfgSxf6UrzAgI=
=/RIv
-----END PGP SIGNATURE-----
19 years, 5 months
FC3rc5
by Elliot Lee
For your weekend enjoyment, please try:
http://fedora.linux.duke.edu/FC3-rc/3/
http://sunsite.mff.cuni.cz/OS/Linux/Dist/Fedora.RC/3/
ftp://sunsite.mff.cuni.cz/OS/Linux/Dist/Fedora.RC/3/
rsync://sunsite.mff.cuni.cz/ftp/OS/Linux/Dist/Fedora.RC/3/
http://testing.fedora.redhat.com/tree/ (still syncing, should be ready by 8pm EDT Oct 29.)
This is likely to be the last FC3 release candidate, so please give it all
the loving attention you possibly can. It does have fixes for some of the
more serious issues reported here - your efforts are having results. When
testing FC3rc5, things that could use extra-special attention are upgrades
and the kernel. Please make sure to file any showstopper bugs (data loss
or corruption, major install/upgrade failures) in bugzilla and bring the
bug #'s to our attention.
In respond to all the queries about "why are the .iso timestamps
changing", it's because I'm putting the latest RC in the same location as
the older ones, so the files do change.
Thanks y'all!
-- Elliot
19 years, 5 months
SPECS files
by Patricio Bruna V
are the specs files availables anywhere beside the srpms packages?
--
Patricio Bruna http://www.linuxcenterla.com
Ingeniero de Proyectos Canada # 239 Piso 5
Red Hat Certified Engineer Providencia, Santiago - CHILE
Linux Center Latinoamerica Fono: +56 2 2745000, Fax : +56 22747075
19 years, 5 months
fedoratracker.org: An update and a request
by Brad Smith
Hi folks,
First the update: Since fedoratracker.org launched the number of
packages indexed by it has increased dramitically. This, as I'm sure
many of you have noticed, has had a very serious affect on
performance. When the problem got so bad that I found myself googling
for packages instead of using my own tool (believe me, that is _not_ a
fun position to be in) I knew something had to be done before FC3 was
released.
So, long story short, over the last several months I've devoted an
inordinate amount of time to comepletely re-writing chunks of the
Tracker's back-end code to improve performance and am pretty happy
with the results.
Improvements in this revision:
----------------------------------------------------------------------------------------------------
- Very significant increases in package search speeds. Listing all
packages in FC1 now takes about 9 seconds, for example. Once the DB
has cached the result, the same search takes only 3 seconds.
- Scalability improvements (so you can expect it to stay fast for the
forseeable future)
- Results are now shown 25 at a time instead of loading every match at
once. I'm open to feedback about whether this number should be
increased.
- You can now search by package category, something I've been wanting
to implement for a long time
- Improved logging and exception handling
Known issues that I will fix when I can, but have no timeframe for
because I have to get back to the Real Job(tm)
----------------------------------------------------------------------------------------------------
- Repository searches can still take about 15-20 seconds. I've figured
out ways to cut this time down significantly but haven't had time to
implement them yet.
- For some reason the fedora.us repos did not index properly during
the last nightly database update. Hopefully this problem will fix
itsself on the next run.
- I just noticed that the link for listing files in a package doesn't
currently show anything. Not sure why this is. Probably a quick fix
once I get around to it.
Please check it out and I hope you find it useful. If you have
comments, questions or bug reports, either respond in this thread or
email brads -at- red hat com.
http://www.fedoratracker.org
--Brad
19 years, 5 months
rawhide report: 20041103 changes
by Build System
Updated Packages:
gettext-0.14.1-12
-----------------
* Mon Nov 01 2004 Leon Ho <llch(a)redhat.com>
- fix call on phase0_getc()
- fix temp file issue (#136323 - CAN-2004-0966 - mjc)
kernel-2.6.9-1.667
------------------
* Tue Nov 02 2004 Dave Jones <davej(a)redhat.com>
- Rebuild.
* Mon Nov 01 2004 Dave Jones <davej(a)redhat.com>
- Fix memory leak on x86-64 in mixed 32/64 mode. (#132947)
- Yet another USB card reader for the whitelist. (#137722)
ppp-2.4.2-6.4.FC3
-----------------
* Tue Nov 02 2004 Thomas Woerner <twoerner(a)redhat.com> 2.4.2-6.4.FC3
- fixed out of bounds memory access, possible DOS
rpmdb-fedora-3-0.20041103
-------------------------
udev-039-6.FC3.1
----------------
* Tue Nov 02 2004 Harald Hoyer <harald(a)redhat.com> - 039-6.FC3.1
- speed up pam_console.dev
- mount pts and shm, in case of the dev trigger
- increased timeout for udevstart
- removed syslog() from signal handler (caused vmware locks)
- turned off logging, which speeds up the boot process
19 years, 5 months
prelink modification ?
by Morten Sylvest Olsen
Hi.
Perhaps experts on prelinking are lurking on this list? :)
I would like to modify prelink to exclude *some* of a binaries needed
libraries from prelinking. So if I depend on library A, B, C then A and
B are prelinked, while normal relocation processing is done for library
C. I guess I could just dlopen the library, but it would be nicer if I
didn't have to manually dlsym 1000 symbols. There might be some
architectural hurdle for doing this, and it would be nice to know before
starting trying to hack the prelink code too much
I have the "usual" problem, namely a dependency on a binary libGL which
has non-pic code included. I cannot use open-source drivers,
unfortunately, and I actually *need* to use OpenGL
With regards, Morten
--
Morten Sylvest Olsen, System Developer
Medical Insight A/S, Hovedgaden 451 C,2640 Hedehusene, Denmark
Phone:+4546550444, Mobile:+4551573092,Mail: mso(a)medical-insight.com
19 years, 5 months
