upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
1 year, 4 months
Cleaning up "Preferred Applications" & Desktop Consistency
by Warren Togami
A while ago I became annoyed enough by the brokenness of this situation
to investigate it seriously. I am now attempting to improve the overall
"Preferred Applications" situation, make cleanups and patch individual
applications to honor the preferred settings. I hope to stir discussion
about further standardization of these aspects of desktop consistency.
Your suggestions would be greatly appreciated. If any new or existing
Bugzilla reports are related to anything below, please reply to let us
know of their locations.
1) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109738
Preferred Applications chooser in the Preferences a.k.a.
control-center's gnome-default-applications-properties sets only the
http gconf key, while there is also a https and unknown key that should
be set. htmlview uses the unknown key while Evolution honors the https key.
/desktop/gnome/url-handlers/http/command
This key is set
/desktop/gnome/url-handlers/https/command
/desktop/gnome/url-handlers/unknown/command
But these two are not set
control-center-2.4.0/capplets/default-applications
The relevant code is within this directory. Ray Strode attached a
patch that sets https, because he disagrees that "unknown" should also
be set. I believe because of the way htmlview currently acts as a
catch-all for anything that needs a web browser, that unknown should
also be set. (htmlview itself is largely broken, this is discussed
later in this message.)
2) need-terminal is the key defined in the gconf schema, but
gnome-default-applications-properties sets needs_terminal. Both Ray
Strode and I agree that this is a typo. His patch corrects this, and it
should be applied to both this package and Gnome CVS.
This means that choosing Links in the chooser as a default browser is
currently broken due to setting the wrong key name. However I have yet
to find a program that actually honors the need-terminal key...
3) On the topic of this gnome-default-applications-properties program,
the way the User Interface currently behaves is somewhat confusing to
end users. When you first launch it, all options are grayed out and
there is no indication if you are using the "Select a Web Browser" or
"Custom Web Browser" chooser. This is especially confusing when you
have set a custom web browser, close, then open it again, and the two
browsers don't match. The user interface needs to be redone in order to
reduce end-user confusion. Any takers?
4) Currently gnome-default-applications-properties's choosers have hard
coded values for options like Mozilla, Konqueror, Epiphany and other
programs. We could do a lot better than this.
I propose that we use desktop-agnostic-easy-install definitions for
Preferred Applications. We should standardize on a directory named
something like /etc/sysconfig/preferred/browser.d within which each
package can easily drop definition files. Each definition file can
contain values like Label, command, need-terminal, etc.
/etc/sysconfig/preferred/mail.d, /etc/sysconfig/preferred/editor.d,
/etc/sysconfig/preferred/terminal.d could be the same for mail clients,
text editors and terminals respectively. Then applications like
"Preferred Applications" can read all definitions from these
standardized directories and populate the chooser with all proper flag
values.
Sane?
5) This brings up the larger question of the need for desktop agnostic
configuration for Preferred Applications as KDE does not use gconf. As
individual applications are improved to honor the Preferred Applications
choice, this completely leaves out the KDE environment especially for
users of other distributions that do not unify the user experience
between Gnome and KDE like Red Hat/Fedora does. In such cases the user
may have only KDE installed, and they may not even have gconf at all,
thus the above gconf-based Preferred Applications breaks down.
This creates a disconnect where KDE development totally ignores this
standard and furthers the divide between the two camps. Otherwise
individual applications need to implement two competing standards (this
standard, plus one lack-of-standard as KDE does not currently have a
notion of Preferred browser). This is a poor situation of greater code
& effort duplication, needless added complication and more bugs.
Is it too late to go back to the drawing board and agree upon a
desktop-agnostic place to configure these things so ANY Linux desktop
software can implement it without requiring gconf? During a transition
period the Preferred Applications chooser can set BOTH the gconf like
previously, and the new standard. Eventually we will phase out all
applications that read gconf (which are currently few) and everyone will
be happy?
6) gconf /desktop/gnome/applications/browser/exec contains the value
"mozilla" by default along with needs_term, and nremote which was
probably meant to mean xremote compatible. This key is untouched by
gnome-default-applications-properties and does not seem to be used by
anything I can find. Am I correct that this is redundant?
Furthermore this lacks consistency, because
gnome-default-applications-properties's Terminal chooser sets
/desktop/gnome/applications/terminal/exec.
7) gaim Preferred Applications integration implementation
I am currently implementing a new default URL handler for gaim called
"Preferred Browser". If gaim upstream does not does not accept it as
default, Fedora's gaim package can choose this new URL handler as default.
Implementation Details:
* Due to the brokenness of xremote in all currently released
Mozilla-compatible browsers and complication with MozillaThunderbird,
some extra care and logic is necessary for proper usage of xremote.
xremote's ping() is completely broken while Thunderbird is running, thus
a workaround like this is needed from a bash script:
exec xremote args && exit 0
Rather than checking if xremote is available, it just goes ahead and to
use it. If it fails then it does not "exit 0" then goes to the next
line of the script which can launch the browser from scratch. Due to
this broken ping() problem, /usr/bin/mozilla script needs fixing. See
this Bugzilla report below comment #35.
* https://bugzilla.fedora.us/show_bug.cgi?id=1113
The script launched from gaim would be very similar to the logic used by
fedora.us MozillaThunderbird open-browser.sh in this Bugzilla report.
8) htmlview is currently flawed, and furthermore its unknown gconf key
behavior is broken due to the above problems with the Preferred
Applications chooser.
I propose that it be rewritten to use gconf's http key by default, and
launch logic similar to the above open-browser.sh. I personally really
dislike its current attempt-to-find-any-installed-browser behavior, and
IMHO it should behave only in a defined and predictable manner by
launching only the Preferred Application.
This includes honoring the need-terminal key to launch the preferred
terminal if in X. I fully support making text-mode browsers the
definable preferred browser in X, as some users like links since it
works great with the mouse and it is very fast & lightweight.
Should we have a separately definable preferred text-mode browser too?
I really question the value of needing to launch a text-mode browser
using htmlview in a non-X terminal. I mean really... does anything
currently depend on that behavior, and would anyone miss it? Let us
please kill that off...
9) After all of the above Preferred Applications mess is cleaned up, I
propose that we make the default panel launchers Web Browser and Mail
Client to launch the chosen Preferred Applications rather than
specifically Mozilla and Evolution. It works great and more importantly
100% predictably.
10) Any other common applications that need patching to honor the
Preferred Applications? Let me know and I will attempt to do so.
11) Evolution's clipboard behavior is currently and always has been
fatally broken. Reproduce: Copy any block of text with newline
formatting from any Evolution window, then paste that into any other window.
Big frown! This alone (and the fact that it takes 3-4 minutes for
Evolution to start with my 50+ IMAP folders) are why I switched to
Thunderbird. We really need to get the clipboard behavior fixed at
least. Please find existing Bugzilla reports related to this... they
have to exist somewhere...
12) Mozilla, MozillaFirebird and MozillaThunderbird use ALT-A for
Select-All within TextAreas and TextBoxes. This is inconsistent with
the default keybindings of all other end-user GUI applications in
Windows, MacOS and even Linux where CTRL-A acts as Select-All. Even
CTRL-A works in non-Text input areas of Mozilla. This is totally
inconsistent and needs to be fixed.
Anecdotally, I do a lot of LTSP and Linux work with schools
indoctrinated by Windows and MacOS. This CTRL-A-fails-to-Select-All
behavior is hit VERY OFTEN during while classes use Mozilla. These
little annoyances everywhere in our desktop software & integration
between applications really add up to a negative feeling toward our
software. We need to strive for greater consistency with all end-user
applications in areas like keybindings, thus ALT-A for Select-All needs
to be changed.
Before the kneejerk reaction, let explain how this came to be. CTRL-A
is historically the "jump to beginning of line" keybinding in Emacs and
command line shells. Thus the Unix hackers much preferred CTRL-A in
text input in Netscape to jump to the beginning of the line.
Unfortunately this conflicts with the well understood "standard" of
CTRL-A being Select-All known by all non-Unix-hackers, and is the
standard keybinding of the vast majority of applications in Linux.
Earlier versions of Mozilla even said "CTRL-A" in the Edit menu as the
keybinding for Select-All, which did not match the behavior. When this
was pointed out by many users, somebody upstream simply changed the
string to read "ALT-A".
I complained about this several times before but was shot down as
NOTABUG by Unix hackers. I wont go as far as to claim that they were
biased. =) Fortunately, recently Christopher Blizzard confirmed that
this is indeed a bug, because Mozilla should be using gtk2's defaults
rather than its own hard coded defaults.
If you look at gtk2 applications like gedit, CTRL-A acts as Select-All.
This is true of most other gtk2 applications and all KDE applications.
Blizzard said that gtk2 has options that allow you to set this
Windows-like behavior, and there is the option to change all keybindings
to be Unix-like globally (where is this setting?). Thus Mozilla needs
to adhere to this configuration option and properly use CTRL-A for
Select-All by default. Knee-jerk reaction Unix people who liked the old
behavior can toggle the gtk2 option and get back the old behavior.
More generally we should make it a standard that all end-user
applications adhere to these common keybindings. Web browsers like
Mozilla *definitely* are end-user applications. This standard of course
does not mandate that developer applications with a tradition of a
different keybinding be changed, so of course Emacs and bash continue to
work as they do today.
Is this sane?
13) In the name of end-user application consistency, Konqueror could use
some extra key-bindings by default to make it behave like Mozilla. The
following do not conflict with current Konqueror defaults.
CTRL-W Close current tab.
CTRL-+ Larger font.
CTRL-- Smaller font.
Other common Mozilla keybindings conflict with already defined Konqueror
bindings, and I really don't feel it is worth the emotional & political
fight to ask that they change.
Any active KDE developers here? Could you please get these checked-in
so it can be in KDE 3.2? RH/Fedora will not apply this change, and we
will only have it if upstream applies it. Please confirm in a reply
when it has been submitted.
Can anyone think of other common Mozilla keybindings that could be easy
to integrate?
Thanks,
Warren Togami
warren(a)togami.com
19 years, 2 months
yum + cache delete files after.
by Balint Cristian
Hi !
Can yum be setted to delete files from /var/cache/yum*** after upgrading/updateing ?
I dig the man but probablyI miss something or is not possible ?
Thanks,
Cristian
--
Life in itself has no meaning.
Life is an opportunity to create meaning.
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
19 years, 2 months
gconfd-2 does not exit when a user log out, breaks unmounting home
by W. Michael Petullo
I have been having some trouble with gconfd-2 (currently using GConf2-2.4.0
from RawHide PPC) for quite some time. I tried to get some discussion going
on Red Hat's Bugzilla quite a while ago but nothing really came of it. I'd
be willing to work on a patch, but I'd like to come to consensus on the
technique we should use to fix the problem. I thought perhaps I would try
this forum.
The gconfd-2 daemon is run by many GNOME applications to manage
configurations. Gconfd-2 remains running for some time after the application
which used it quits. This allows other applications to use gconfd-2 without
having to start and stop the daemon too much. This is a good idea.
The problem comes when a system tries to unmount a user's home directory when
the user logs out. For example, pam_mount unmounts an encrypted home
directory then I log out of my system. Other people use NFS or other means
to mount home directories.
Gconfd-2 continues to run even when a user logs out. This causes the
unmounting of the user's home directory to fail because gconfd-2 keeps the
following files open:
/home/user/.gconfd/saved_state
In addition, when using GNOME 2.4, there are four new programs that seem to
hang around unwelcome for a second after logging out (at least they are still
around when PAM session closing code is run). This is partially documented
in bug #106826. The four programs are:
bonobo-activation-server (home direcotry remains open as CWD?)
gnome-settings-daemon (home direcotry remains open as CWD?)
xscreensaver -nosplash (home direcotry remains open as CWD?)
mapping-daemon (home direcotry remains open as CWD?)
Red Hat Bugzilla bugs #67605, #75895 and #106826 comment more on this
problem.
--
Mike
19 years, 3 months
Perl 5.8.2 in Rawhide
by Chip Turner
Perl 5.8.2 has been built in Rawhide. It has an initial attempt at
binary compatibility when embedded in previous perl's, but I'd
recompile anything embedding perl "just in case." Mainly this is
mod_perl, xchat2, and gaim these days, IIRC. Perl modules should work
fine as-is. mod_perl also should now be 1.99_11, the upstream
latest. Let me know if anything is broken. 5.8.2 and 1.99_11
probably both work on FC1, too. In fact, if people would like to help
test that, once we see that it is stable, I'd like to errata it into
FC1, assuming there is enough demand and enough testing :)
Chip
--
Chip Turner cturner(a)redhat.com
Red Hat, Inc.
19 years, 3 months
Re: Fedora minimal install option
by MG
02-Dec-2003 fedora-devel-list-request(a)redhat.com:
> From: Robert Marcano <robert(a)marcanoonline.com>
>
> If I remember correctly, you can use the custom option, and on the
> package selection screen yo can choose Minimum Install or Full Install,
> the last two options (The last time i saw those options was using RH9, i
> don't remember if Fedora still has them)
>
The custom install allow the packages selection. But I could not see it in the
Fedore Core 1. :(
If I don't select packages in the custom install option, then the Linux (Fedora
and RH9) install ~900MB. It is too many for minimal. It contains many
packages that are not necessary (for examples redhat-artwork etc.).
> From: Klaasjan Brand <kjb(a)dds.nl>
>
> I don't know exactly how small you can get Fedora (anyone? :), but you
I would like the absolute minimal packages! :)
> can do a custom install and only install packages you really need. If
> you create a "kickstart" install script you can repeat the same
> installation for multiple systems.
>
Kickstart? How can I create it?
> From: Rui Miguel Seabra <rms(a)1407.org>
>
> I haven't looked into Fedora Core's Minimum Install yet, but RedHat's
> Minimum Install is _all_but_minimal_.
>
I haven't seen the minimal install option in RedHat.
> A Minimum Install should look _almost_ like an OpenBSD default boot:
>
> No services active (BECAUSE THEY'RE NOT EVEN INSTALLED)
> NO X.
> Just the necessary to boot and make post install installations.
>
Yes, I want it! :)
I would like minimal install then reboot system and if necessary I install
the additional packages (like Debian Linux :)).
Bye!
Gabor
19 years, 4 months
Permissions problem
by Arvind Narayanan
Hi,
I'm running FC1. I have a problem which was there with
RH7.x as well: The ownership of files like /dev/fd0 and
/dev/dsp don't work correctly, i.e they continue to belong
to the user who logged out earlier rather than the
user who just logged in. Worse, this I am not able to
deterministically reproduce this, it only happens sometimes.
Any suggestions? Thanks
Arvind
--
Its all GNU to me
19 years, 4 months
RE: initscripts: Can it restart a service automatically if onecrashes?
by Erik LaBianca
>
> erik(a)totalcirculation.com ("Erik LaBianca") writes:
>
> > Another possibility is to use daemontools...
>
> Indeed, they are very usefully. But unfortunately, they are
> not free software (like all the other djb stuff) and can not
> be distributed therefore.
>
>
Are you sure daemontools isn't public domain?
This is all I see:
[erik@mises BUILD]$ head -1 daemontools/src/alloc.c
/* Public domain. */
I've heard tell that djb doesn't like binary redistribution of patched
binaries, but I don't see anything about it in the current daemontools
distro. He also has a treatise[1] about how he declaring code to be in
the public domain effectively relinquishes copyright. He does have a
redistribution page indidicating he doesn't want anyone to ship versions
of his software installed in a "non-standard" location, however [2].
Anyway, it looks like there may be some other replacements that might be
suitable alternative. It sure would be nice to have a simpler (read not
sysvinit) way to add "services" to a fedora system included with the
distro.
1. http://cr.yp.to/publicdomain.html
2. http://cr.yp.to/distributors.html
--erik
19 years, 4 months
Proposal: rpm-4.2.2 should refuse to build as root
by Warren Togami
Proposal
========
rpm-4.2.2 in rawhide and all future versions should refuse to install
SRPMS & build packages as root by default. Optionally add a .rpmmacro
option to re-enable it, but only mention that option for advanced users
on rpm.org to really discourage its use.
This would go a long way toward discouraging the improper and sometimes
dangerous practice of building RPMS as root. By breaking this improper
practice, this also encourages upstream projects to fix their broken
Makefiles to easily allow installation into a different DESTDIR [1].
Many repositories out there also have simply broken packages due to
laziness [2], and they too would eventually be forced into correctness
by this rule. Note that fakeroot [3] seems to solve this problem, it is
looked upon unfavorably as being suitable for use in Fedora, as it is
only a poor excuse that further encourages improper upstream Makefiles.
[ -n "$RPM_BUILD_ROOT" -a "$RPM_BUILD_ROOT" != / ] && rm -rf $RPM_BUILD_ROOT
This would also completely solve this silly urban legend surrounding
this ugly construct found within many spec files. If users cannot build
as root, then BuildRoot being equal to "/" (which is incredibly unlikely
to begin with) cannot destroy their system.
It is also exceedingly simple to begin using a non-root RPM build
environment if the user is pointed to proper documentation. Thus
something like the following error message should display when rpmbuild
refuses to work:
========================================================================
ERROR: rpmbuild should not run as root for security reasons. All proper
RPM packages should be buildable as non-root users. If your rpmbuild
fails as a non-root user, then it is usually a Makefile or packaging bug
that needs to be corrected.
http://www.rpm.org/rpmbuild-nonroot
Please read this page for HOWTO easily setup your non-root rpmbuild
environment, and tips for fixing typical Makefiles and specs to properly
work in such non-root environments.
========================================================================
The webpage can contain Russ Herrold's script, installable within
fedora-rpmdevtools, and equivalent packages for other distributions.
Sane idea?
Warren Togami
warren(a)togami.com
[1]
Broken Makefile examples
http://www.inter7.com/vpopmail.html
http://www.rhyolite.com/anti-spam/dcc/
[2]
Lazy, improper, but popular packages example
http://www.qmailtoaster.com/
[3]
fakeroot discussion at fedora.us
http://www.fedora.us/pipermail/fedora-devel/2003-December/002439.html
http://www.fedora.us/pipermail/fedora-devel/2003-December/002440.html
http://www.fedora.us/pipermail/fedora-devel/2003-December/002443.html
19 years, 4 months
lilo -R equivalent in grub?
by Warren Togami
I just learned about the awesome "lilo -R" command. The man page says:
-R command line
This option sets the default command for the boot loader the next
time it executes. The boot loader will then erase this line: this is
a once-only command. It is typically used in reboot scripts, just
before calling ‘shutdown -r’.
This allows you to test new kernels on remote servers, and it will
revert back to the lilo.conf default during the next boot. A regular
reboot, remote power cycle, or passing 'panic=10' kernel option which
reboots upon panic would fallback to the previous default.
Does GRUB have anything similar to lilo's -R? This is a totally useful
function and I would really like to avoid using lilo.
If this functionality is truly missing from GRUB then this is another
project for me.
Warren
19 years, 4 months
