Re: RPM problem: prereq: <file> not honored in upgrade ordering?
by Jef Spaleta
Pekka Savola wrote:
> .. I upgraded between RHL72 and RHL73 using autoupdate, and the
> updating of RPM's is done basically by 'rpm -Uvh <long list of RPMs>'.
done basically. by ...or done exactly by. I'm a bit suspicious that the
problem lies with the perl script autoupdate and not necessarily
rpm...but you could certainly test whether its a problem with rpm.
If you can rollback the changes you made then place the updates you did
in a local directory then do rpm -Uvh or -Fvh on that local
directory..without using autoUpdate...you should be able to determine if
it is in fact a problem with rpm.
But even if you do determine it is a bug in rpm....the version of rpm
might not be so relevant to the current version in the fedora test
releases :->.
-jef
20 years, 6 months
Fedora and RedHat's autism toward personal users
by Jean Francois Martinez
Probably because RedHat thought that personal users wouldn't buy
support it has ever tended to neglect them: let's remember
the good old times where RedHat ignored dial-up users and assumed
everyone was on Ethernet. :-)
<p>
In RedHat 9 we still have no tools to configure ADSL modems on USB
and it still does not provide for masquerading. Software selection
also tends to be quite austere.
Since Fedora is a community project and doesn't have the same
constraints than RedHat (make PAYING users happy or bankrupt) I
think it would be time to pay more attention to personal users
through solving their specific problems (see above) and with a sexier,
funnier software selection. One of this would be Blender. Also take
a look at what is included in Mandrake
BTW I am NOT for advocating for including every piece of cr.p, like
Debian does (in an ideal world Feddora would include only one program
for a task: the best one, in real world it is more complex) and I am
quite conscious that it is not possible to cover every need in world.
--
Jean Francois Martinez <jfm512(a)free.fr>
20 years, 6 months
RPM problem: prereq: <file> not honored in upgrade ordering?
by Pekka Savola
Hi,
This is semi-offtopic here, but is relevant to see whether this issue has
since then been fixed.
When I was upgrading a RHL72 box to RHL73, I noticed that
/usr/sbin/sendmail symlink was not added by the alternatives (done at
%post of sendmail). RHL72 didn't have alternatives, but sendmail.spec
does have:
Prereq: /usr/sbin/alternatives
.. I upgraded between RHL72 and RHL73 using autoupdate, and the updating
of RPM's is done basically by 'rpm -Uvh <long list of RPMs>'.
>From the logs I note that sendmail was installed before a newer
version of chkconfig which would have provided /usr/sbin/alternatives.
Thus, no /usr/sbin/alternatives existed when sendmail was upgraded, and
the link failed.
I think this smells like a problem in the ordering RPM uses to upgrade the
packages?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
20 years, 6 months
Re: Yo.
by Nils O. Selåsdal
On Tue, 2003-10-14 at 21:19, Oden Eriksson wrote:
> Hi Folks,
>
> I've been involved in many aspects of the Mandrake Linux evolution and done
> many great things there. Lately I feel the focus has changed to the worse,
> and I'm not happy about it. What can you say to convince me to join this
> community?
What do you feel have gone worse with Mandrake ?
Anyway, http://fedora.redhat.com/ describes what Fedora is and is not.
Take your time to read that, and decide wether you want to be part of
it.
--
Vennlig hilsen/Best Regards
Nils Olav Selåsdal
System Engineer
UtelSystems a/s
w w w . u t e l s y s t e m s . c o m
20 years, 6 months
First Unofficial Fedora Bug Day: Tomorrow err I mean Today!!!!!!!!!
by Jef Spaleta
What: Fedora Bug Day!!!!!
When: Oct 15 09:00 EDT about 21:00 EDT
Where: #fedora-bugs on the freenode irc network
Why: to clean up bugzilla bug reports that need more info
Who: Anyone who wants to help make the fedora developers more
efficient
In an effort to get the ball rolling on a fedora community based
bugzilla triage effort, I am hereby decreeing that tomorrow
Wednesday October 15, 2003 the first unofficial Fedora Bug day, and
every Weds there after to be Fedora Bug Days until the end of time, or
someone more competent wants to be in charge and wants to change the
date. In an effort to control the chaos, during tomorrow's first attempt
at this..I want to try to focus effort on bugs that need more
information to be useful. I'd like to also like to encourage anyone
interested in translation work to possibly take this bug day opportunity
to take a crack at going back and sweeping up outstanding translation
bugtickets in bugzilla. The goal here isn't to create a whole new set of
bugs, the goal is to get as many existing bugs as possible closed..or at
the very least in shape to be closed by developers.
"But Jef...what exactly is the point of a Bug Day?"
Good question. The basic idea of a Fedora Bug Day, is a chance for
us...the Fedora community to spend some quality time cleaning up Fedora
bugzilla so the developers can spend less time sifting through lots of
duplicate or incomplete bug reports and spend more time fixing bugs that
can be fixed right away. The basic concept of bugzilla triage is that
community members go through bugzilla fixing up bug reports that need
information or confirmation so developers don't have to do this sort of
routine day-to-day maintenance, and hopefully as a result developers
spend more time fixing bugs than they do asking for clarifying
information in bugreports.
The Gnome bugsquad project is a good starting point in the process of
building guidelines and policies for people interested in helping out in
the fedora bugzilla triage effort:
http://developer.gnome.org/projects/bugsquad
And specifically for those people interested in participating in
Fedora Bug Days, reading about how Gnome handles bug days would be
quite useful:
http://developer.gnome.org/projects/bugsquad/triage/faq.html#II
Gnome's bugsquad project idea relies heavily on having trusted community
members being able to modify existing bugreports. And eventually I hope
to have a core group of fedora community members with the same sort of
access to edit bugsreports (without stepping on the toes of the existing
Red Hat QA team of course)...but in the beginning we can do a lot just
by focusing on the bugs that need more information and working to fill
those in, so the bugs can be closed by developers.
So tomorrow...if you have some time, try to read over how Gnome handles
triage, and then try to find open bugs in redhat's/fedora's bugzilla
that are in need of more information (log files or certain command
output for example). And please drop into the #fedora-bugs channel to
ask questions about the triage efforts or to wax eloquent on how to make
this community based triage idea more useful for everbody.
-jef"www.homestarrunner.com is not a good reference for learning about
bugzilla triage"spaleta
20 years, 6 months
How can I get more involved???
by Brian Dee
Don't laugh!! ; ) I'm a CS major at my local university and have been
using Linux, specifically RedHat, for the past four years or so. I have
benefited greatly from using it, tweaking it, breaking it, fixing it,
etc. I greatly enjoy the friendly and helpful Linux and open source
communities. I want to give back and at the same time "beef up" my
skills in programming, administration, or whatever.
Can any of you share how you get started in this big wide world of Linux
hacking? I mean, I've read many things about it such as "Find a bug and
fix it.", "Help with documentation.", etc. But, I still am not sure what
I can do, or where to start. I have some programming experience with
several languages, but unless you use them really in depth, you just
don't learn them very well. You know? I can take all the requirements
for my BS, but unless I can actually find ways to use the things I'm
learning, I'll forget them. Just like any kind of talent. So, how do you
get started? I enjoy Python a TON, and have built a few personal
utilities with it for my job, including a pyGTK based thingamajig that
helps me with an administration task I face frequently. Mostly just fun
self tutorials and stuff. I would love to just do *something* that would
be useful for others and fun for me to do.
Anyway, I would appreciate any advice or guidance anyone has. Thanks for
contributing *your* time and talents that has made this such a great
ride!!!
-- Brian Dee
20 years, 6 months
Redhat-Config-XFree86
by Matt Jones
Hi - The dual head support doesn't seem to work for me (i'm on a toshiba
satellite 1405-s151 laptop) via redhat-config-xfree86. Whenever I
restart my X server, it merely clones my X screen onto my external
monitor. Looking at my logs, it shows TRIDENT(0) as picking up both
monitors. Should this be happening? I'm assuming that TRIDENT(0) should
only be detecting the lcd, and that TRIDENT(1) should pick up the
monitor.
Thanks,
Matt Jones
20 years, 6 months
Suggestions for the Installer (regarding network installs)
by Stephan Windischmann
Recently, I installed the Fedora beta on my laptop to replace Debian
unstable, and since I'm not going to download 3 ISO's on my 128kbit
connection, I decided to try the netinstall using the 4MB boot.iso.
It seems as if the netinstall function is only there as an afterthought
(or maybe I'm just used to Debian).
Instead of a 4MB boot CD that has to download the installer itself, a
dedicated Fedora Netinstall CD (~100-150MB) that has the graphical
installer and perhaps a minimal file system on it would be really
helpful for those that don't want to get all 3 CD's.
Having to enter the FTP mirror details by hand isn't especially user
friendly either, and it doesn't really fit together with the rest of the
Fedora installer, which is excellent.
Also, would it be possible to do a netinstall of rawhide directly,
instead of having to first install the latest beta/release and then
upgrading to it? I'm a software version junky. ;)
Enough ramblings for now.
-windi
20 years, 6 months
Re: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
by Owen Taylor
[ CC'ing and setting Reply-To to fedora-devel ]
On Sun, 2003-10-05 at 07:47, Jaap A. Haitsma wrote:
> I've installed Severn including all the updates (except Mozilla because
> mozilla mail seems to freeze according to all the posts on this list
> after updating) on my laptop (A Dell Latitude C600).
>
> First thing I noticed that booting was a lot slower (I even thought the
> init script was frozen). Then I changed the GRAPHICAL_BOOT variable in
> /etc/syconfig/init to no. Booting time reduced from 2 minutes till 1 minute.
>
> The problem seems to be the kudzu service, which probes for new devices.
> If I disable the kudzu service a graphical boot takes also 1 minute.
>
> Anybody experiencing the same thing?
The problem is likely that kudzu thinks your hardware has changed and
is patiently waiting on the other screen waiting you to press a key.
This will add 30 seconds to the boot time. Then by disabling kudzu
you gain another 8-10 seconds.
Jonathan and Bill are working on a fix for this; if kudzu wants to
interact with the user, a vte terminal will appear on the graphical
boot screen.
I did some timing of booting with and without rhgb this evening and
the conclusion is that rhgb slows the entire boot
(on a PIII-700 with a similar-era hard drive) by about 20 seconds,
from ~1:00 to ~1:20.
This slow down is virtually all in starting up rhgb ... from the
point where X takes control to the point where rhgb appears on the
screen is just about 20 seconds; likely this time is mostly spent
simply reading in libraries from disk, though there are some puzzling
factors:
- When booting up without rhgb, starting gdm (X => appears on screen)
takes around 10 seconds. But gdm uses all the libraries that
rhgb uses and more.
- gdm is no faster to start when rhgb has started before, even though
many of the libraries that gdm needs should already be in ram.
- Running rhgb from runlevel 3 "hot" takes about 4 seconds from
X => appears on screen.
- Running gdm from runlevel 3 "hot" takes about 5 seconds from
X => appears on screen.
Possible explanations of these facts that really don't convince me:
A) Many of the libraries used by rhgb and gdm are used by various
bits of the init process and are loaded parallelized with
other tasks between the point that rhgb starts and the point
that gdm starts. (This only makes sense if most of the load time for
rhgb was non-GUI libraries. Which I don't believe.)
B) One of the init steps that runs *after* we start rhgb speeds up
the system by a large factor. (What? /etc/sysconfig/harddisks
is run later but does nothing on this test system)
Next thing I want to do is to boot into runlevel 3 and see how long
rhgb takes to run cold there.
(Both A) and B) predict that it should take around 9-10 seconds, so it
can't distinguish between them. But if it takes much longer that would
tend to disprove both of them.)
Regards,
Owen
20 years, 6 months