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
2 years, 3 months
autoconf breakage on x86_64.
by Sam Varshavchik
I don't know the right way to fix this, but something is definitely broken;
and something needs to be fixed, one way or the other. The question is what
exactly needs to be fixed.
Consider something like this:
LIBS="-lresolv $LIBS"
AC_TRY_LINK_FUNC(res_query, AC_MSG_RESULT(yes), AC_MSG_RESULT(no))
Here's what happens on x86_64:
gcc -o conftest -g -O2 -Wall -I.. -I./.. conftest.c -lresolv >&5
/tmp/ccW7EeDX.o(.text+0x7): In function `main':
/home/mrsam/src/courier/authlib/configure:5160: undefined reference to
`res_query'
collect2: ld returned 1 exit status
configure:5147: $? = 1
configure: failed program was:
[ blah blah blah ]
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char res_query ();
| int
| main ()
| {
| res_query ();
| ;
| return 0;
| }
The same exact test on FC1 x86 will work.
The reason appears to be that you have to #include <resolv.conf> on x86_64
in order to succesfully pull res_query() out of libresolv.so. You don't
need to do this on x86, and the test program generated by AC_TRY_LINK_FUNC
does not include any headers, but uses a manual prototype.
So, what now?
17 years, 7 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
20 years, 1 month
Using bit torrent to retrieve RPMs for updates
by Jonathan Gardner
Has anyone given serious thought to changing Yum so that it uses the
bittorrent protocol to retrieve RPMs? Especially in the case of updates,
when everyone and their grandmother needs to get the RPMs right away, this
would make a lot of sense. Yum could manage a repository of RPMs and
constantly serve those up so other can download parts of them via
bittorrent, all with permission, of course.
--
Jonathan Gardner
jgardner(a)jonathangardner.net
20 years, 1 month
Re: include php-imap in FC2 (bug #115535)
by Kaj J. Niemi
> I'm also able to package the c-client library based on the previous imap
> rpm if that is the conclusion of this discussion.
Attached is a suggestion for libc-client.spec. It is based on the imap-2002d
package. A shared library is built in addition to the static library. The
build code was borrowed from FreeBSD's ports collection mail/cclient where
it has been working well. In the base package we install just the shared
library while the header files and the static library gets saved for -devel.
The .spec and the .src.rpm can be found at <http://www.a51.org/sw/fedora/>.
Comments are welcome.
// kaj
20 years, 1 month
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_/
20 years, 1 month
How to help with SELinux
by Elliot Lee
Since FC2t2 was just delayed due to SELinux, no doubt you're wondering
"How do I help with SELinux hacking so I can get my hands on test2?"
The simplest way is to install from rawhide, use the system in as many
ways as you can, and file bug reports against the 'policy' package for any
'avc: denied' messages that show up in the system logs. Please make sure
to check that the bug hasn't already been filed. Try to include all the
information on the problem:
The 'avc: denied' messages themselves.
How to reproduce them:
Which program to run or actions to take
What environment to reproduce in - root login or regular
user login, su session, sudo session, graphical or text
environment, etc.
Whether SELinux in enforcing mode
What file system type (ext3, NFS) might be involved in the
bug
Whether or not you have rebooted since last upgrading your
policy package.
What version of the policy package you have installed
('rpm -q policy')
If you want to go beyond just reporting problems, an even better thing to
do is to write policy to fix the problems you find, and then submit the
policy changes. There are tons of things we have never tried and are
almost guaranteed to blow up. If we have to write policy for all of them,
it will take a very long time.
The audit2allow utility (part of the policycoreutils package) may be
useful here.
If you want to know more about SELinux and writing policies for it, you
can visit http://www.tresys.com/selinux/selinux-course-outline.html
Another tack to take when writing policies is to look at existing policies
for similar programs. For example, if you're writing a policy for rshd,
the policy for sshd might make a good start.
(Kudos to Dan Walsh for all the content here)
-- Elliot
20 years, 1 month
Fedora Core 2 Test 2 - delayed
by Bill Nottingham
We're encountering various issues that are causing us to delay
the release of test2. We'd like to get as much exposure to SELinux
as possible, and this means shipping test2 with SELinux in
enforcing mode. However, there are still some subsystems that
aren't quite ready for this, so we need to slide the release
date some.
The *current* projection is that the freeze will be on March 12,
for availability on March 22. This date is only preliminary at
this point, and may change. The schedule at:
http://fedora.redhat.com/participate/schedule/
will be updated shortly.
Bill
20 years, 1 month
Prelink success story :)
by Keith G. Robertson-Turner
Guess I've been lucky, but I never really suffered much from the various
prelink related problems that have been reported.
A total of 2 applications (out of 1603 packages) were bØrked by prelink
on my system, since FC1 was released, namely k3b and kdepim (in fact they
still get bØrked even now by prelink).
Being rather pleased with myself for having a 99.88% perfect system, I
took the (maybe) risky step of chasing after the other 0.12%.
I got prelink-0.3.0-21 from (Fedora devel) rawhide, but it needs SELinux.
After getting the SRPM and looking at the spec, I don't see SELinux
listed? Anyway, after some minor modification to the spec (mainly to
satisfy rpmlint) I rebuilt on a clean mach chroot and installed.
Of course the whole purpose of the exercise was to get blacklist support,
so I edited prelink.conf and added twenty or so files that I'd flagged as
problem files (all part of the above two apps). I ran a full prelink and
crossed my finger.
Result: no problems at all. No segfaults and no bØrked apps. Also, and
maybe this is my imagination, but everything seems to be running a *lot*
faster ... even more than after previous prelinking. Even the log file was
relatively clear (just a few complaints about "x" can't be prelinked
because it depends on "y" which also can't be prelinked ... etc. Normal
stuff.
Now for some questions ... not gripes ... just curiosity:
1) ... Is Jakub Jelinek really the *only* guy working on this?
2) ... Other than in the SRPM, where's the source Luke :)
prelink-20040216.tar.bz2 is missing from people.redhat.com/jakub/prelink
3) ... Why was macros.prelink hard coded into the spec as a text block,
rather than as a SourceX file?
4) ... Why isn't there a logrotate file to accompany the included log
file, and come to that, why *package* a log file? Or am I missing
something obvious?
Other minor (rpmlint) observations:
Use of "Copyright" instead of "License"
Weird 555 and 444 perms
Ghost-without-post errors
Use of "/etc" instead of %{_sysconfdir}
Use of %{buildroot} instead of $RPM_BUILD_ROOT (although that seems to be
a point of contention these days, personally I prefer %{buildroot}, since
it is more consistent with the other spec conventions.
Anyway, I'm just really pleased to have blacklist support in prelink
finally, which I guess leads me to one final question ... why hasn't this
version been officially released yet? (Although maybe I've answered this
already above, but the cleaned up version looks pretty good).
Oh, and ... thank you Jakub.
-
K.
20 years, 1 month
rawhide report: 20040228 changes
by Build System
New package gnome-netstatus
Network status applet
New package perl-RPM-Specfile
RPM-Specfile Perl module
New package perl-XML-LibXML-Common
XML-LibXML-Common Perl module
Updated Packages:
XFree86-4.3.0-61
----------------
* Fri Feb 27 2004 Mike A. Harris <mharris(a)redhat.com> 4.3.0-61
- Added XFree86-4.3.0-keyboard-disable-ioport-access-v3.patch as a final patch
without debug logging enabled, to fix (#115769)
- Added spec file macro 'with_savetemps' for debugging purposes, disabling it
by default. When used, it is set up to only get used on x86 for
build_rawhide and build_psyche builds
- Added XFree86-4.3.0-ati-ia64-no-nonpci-ioport-access.patch to fix ati driver
issue on ia64 which causes IBM x455 system to machine check. Also added
"#define ATIAvoidNonPCI YES" to host.def to activate this fix only on ia64
builds (#112175)
* Wed Feb 25 2004 Mike A. Harris <mharris(a)redhat.com> 4.3.0-60
- Added XFree86-4.3.0-keyboard-disable-ioport-access-v2.patch to try to
fix (#115769)
- Changed mkxauth to call chown as foo:bar instead of foo.bar as the latter
syntax has been deprecated
- Added XFree86-4.3.0-minor-typo.patch to fix a trivial typo that I spotted
in an error message in linux int10 code.
- Remove Buildrequires kudzu-devel, pciutils-devel, both of which were added
on Mar 21, 2001 when Glide3 was included in the XFree86 packaging, but are
no longer necessary. I detected this when the buildsystem failed my build
due to being unable to meet the dependancy on kudzu-devel, and further
investigation showed that dependancy is no longer necessary.
- Added XFree86-4.3.0-xcursorgen-check-malloc-return.patch to make xcursorgen
check the return codes on malloc before referencing allocated memory
- Added XFree86-4.3.0-redhat-xcursorgen-do-not-build-included-cursors.patch to
stop building the XFree86 supplied Xcursor cursors as we do not ship them
* Thu Feb 19 2004 Mike A. Harris <mharris(a)redhat.com> 4.3.0-59
- Added XFree86-4.3.0-xrandr-manpage-typo-fix.patch to fix manpage (#83702)
- Added XFree86-4.3.0-radeon-9200-dvi-snow.patch to fix issue on Radeon 9200
when using DVI panel and encountering snow and other artifacts (#112073)
- Updated XFree86-4.3.0-debug-logging-ioport-based-rate-setting.patch to have
it patch both lnx_kbd.c and lnx_io.c because both files insanely contain
identical cut and pasted copies of the exact same source code, so nothing
shows up in the X server log when testing with previous patch as the calls
never got invoked in lnx_kbd.c (#115769)
gail-1.5.6-1
------------
* Wed Feb 25 2004 Alexander Larsson <alexl(a)redhat.com> 1.5.6-1
- update to 2.5.6
gimp-print-4.2.6-8
------------------
* Fri Feb 27 2004 Tim Waugh <twaugh(a)redhat.com> 4.2.6-8
- Fixed dither algorithm selection (bug #116516).
- Fixed another plug-in crash.
glibc-2.3.3-12
--------------
* Fri Feb 27 2004 Jakub Jelinek <jakub(a)redhat.com> 2.3.3-12
- update from CVS
* Fri Feb 27 2004 Jakub Jelinek <jakub(a)redhat.com> 2.3.3-11
- update from CVS
- fix ld.so when vDSO is randomized
gnome-applets-2.5.6-1
---------------------
* Thu Feb 26 2004 Alexander Larsson <alexl(a)redhat.com> 1:2.5.6-1
- update to 2..5.6
gnome-panel-2.5.90-1
--------------------
* Fri Feb 27 2004 Mark McLoughlin <markmc(a)redhat.com> 2.5.90-1
- Update to 2.5.90
- Resolve conflicts with the lockf patch and re-work slightly
gstreamer-plugins-0.7.5-1
-------------------------
* Fri Feb 27 2004 Alexander Larsson <alexl(a)redhat.com> 0.7.5-1
- update to 0.7.5
* Fri Feb 13 2004 Elliot Lee <sopwith(a)redhat.com>
- rebuilt
gtk2-2.3.4-1
------------
* Wed Feb 25 2004 Mark McLoughlin <markmc(a)redhat.com> 2.3.4-1
- Update to 2.3.4
- Remove the xft-prefs patch, its upstream now
- Don't kill libtool's hardcode_libdir_flag_spec anymore
im-sdk-11.4-19
--------------
* Fri Feb 27 2004 Akira TAGOH <tagoh(a)redhat.com> 1:11.4-19
- im-sdk-11.4-canna-no-process-unrelated-keys.patch: applied to allow working
unrelated keys during no preediting. (#114002)
- im-sdk-11.4-canna-draw-off-status.patch: fixed crash issue.
kernel-2.6.3-1.116
------------------
* Fri Feb 27 2004 Dave Jones <davej(a)redhat.com>
- Update to 2.6.4-rc1
- Re-enable Future Domain SCSI controller.
libaio-0.3.98-2
---------------
* Thu Feb 26 2004 Jeff Moyer <jmoyer(a)redhat.com> 0.3.98-2
- bah. fix version nr in changelog.
* Thu Feb 26 2004 Jeff Moyer <jmoyer(a)redhat.com> 0.3.98-1
- fix compiler warnings.
* Thu Feb 26 2004 Jeff Moyer <jmoyer(a)redhat.com> 0.3.97-2
- make srpm was using rpm to do a build. changed that to use rpmbuild if
it exists, and fallback to rpm if it doesn't.
pam-0.77-36
-----------
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 0.77-36
- fix tty handling
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 0.77-35
- remove tty closing and opening from pam_selinux, it does not work.
* Fri Feb 13 2004 Elliot Lee <sopwith(a)redhat.com>
- rebuilt
policy-1.6-13
-------------
* Fri Feb 27 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-13
- Add Russell etc_domain stuff
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-12
- Fix fd inheritance
* Thu Feb 26 2004 Dan Walsh <dwalsh(a)redhat.com> 1.6-11
- fix locate
rpm-4.3-0.16
------------
* Wed Feb 25 2004 Jeff Johnson <jbj(a)jbj.org> 4.3-0.15
- serialize rpmtsRun() using fcntl on /var/lock/rpm/transaction.
rpmdb-fedora-1.90-0.20040228
----------------------------
sound-juicer-0.5.10.1-3
-----------------------
* Fri Feb 27 2004 Brent Fox <bfox(a)redhat.com> 0.5.10.1-3
- rebuild
20 years, 1 month
