devel December 2003

devel@lists.fedoraproject.org

273 participants
292 discussions

upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse 17 Jan '22

17 Jan '22

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

6 9

Cleaning up "Preferred Applications" & Desktop Consistency
by Warren Togami 16 Mar '04

16 Mar '04

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

9 22

yum + cache delete files after.
by Balint Cristian 05 Mar '04

05 Mar '04

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_/

3 3

gconfd-2 does not exit when a user log out, breaks unmounting home
by W. Michael Petullo 17 Feb '04

17 Feb '04

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

5 15

Perl 5.8.2 in Rawhide
by Chip Turner 13 Feb '04

13 Feb '04

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.

4 8

Re: Fedora minimal install option
by MG 19 Jan '04

19 Jan '04

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

9 9

Permissions problem
by Arvind Narayanan 12 Jan '04

12 Jan '04

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

5 6

RE: initscripts: Can it restart a service automatically if onecrashes?
by Erik LaBianca 08 Jan '04

08 Jan '04

> > 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

2 1

Proposal: rpm-4.2.2 should refuse to build as root
by Warren Togami 07 Jan '04

07 Jan '04

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

18 19

lilo -R equivalent in grub?
by Warren Togami 06 Jan '04

06 Jan '04

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

7 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel December 2003