devel October 2003

devel@lists.fedoraproject.org

203 participants
210 discussions

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

Distags in rpm sort order (yes, versioning again ;)
by Axel Thimm 08 Nov '03

08 Nov '03

Bringing up this topic again, since it was left unresolved. I won't go into details again, about *why* a disttag is needed and why it has to adhear to rpm internal sort algorithms. Please check the following threads in doubt (and discuss the reasons there please, help keeping this thread constructive this time ;): http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00272.html http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00551.ht… http://www.redhat.com/archives/fedora-devel-list/2003-September/msg00263.ht… The bottom line is that distags are needed if one wants to create packages for the same upstream sources but built for different distributions. Disttags can then be embedded in the release tag to ensure proper upgradability. ==================== Disttag schemes: pick one! Here are the discussed schemes (some others exist with small variations, e.g. fc instead of fdr, or no fdr tag at all, the discussion is the same). Default versioning is (no cvs/beta, kernel modules and special cases, leave that for another thread): <name>-<upstream version>-<releasenumber><disttag><non sort relevant suffixes, e.g. repoid> e.g. simply foo-1.2.3-4.<disttag>.johnsmith disttag can be: A B C Red Hat Linux 7.3 fdr0.7.3 rh7.3 rh7.3 Red Hat Linux 8.0 fdr0.8.0 rh8.0 rh8.0 Red Hat Linux 9 fdr0.9 rh9 rh9 Fedora Core 1 fdr1 rh9.1 1fdr Fedora Core 2 test1 fdr1.95 rh9.1.95 1.95fdr A) + consistent distid + future tagging will be self-explanatory + fits nicer into a general nameing scheme (e.g. not only RHL and FDR, but RHEL and non-RH could use, or allready do use the <disttag>:=<distid><distversion> idiom) - obfuscates RHL <= 9 rpm versioning - requires rebuilding of existing 3rd party repos for the sake of versioning. o requires a statement from redhat to allow calling RH 7.3 as FDR 0.7.3 for instance, e.g. the "old" RHL product is officially conamed Fedora 0.something B) + current practice for many repos offering rpms build form the same upstream sources for more than one distribution. + keeps current 3rd party repos from rebuilding all the old rpms just for reversioning (and users from redownloading the same rpms with a new name) - does not pertain the strict separation RHL <-> FDR, and may cause confusion. o A) is preferable, but B) may be a nice transition solution for existing installations. C) + visually pertains separation of rh and fdr releases - is a kludgy workaround using rpm semantics present only after RHL9, thus breaking upgrading from RH8.0 and less (note that rpm errata for fixing this rpm bug and others are still not officially available) - number prefixing breaks when the preceding expression is numeric separated with dots or underscores, e.g. foo-1.2.3-1.1_rh9 > foo-1.2.3-1_1fdr (the stems here are "foo-1.2.3-1.1" < "foo-1.2.3-1") Using decimal release tags needs to be separately considered, but the fact is that they are being used often. - reverses order of distid and distversion - Variant "1fdr<version>" keeps order of distid and distversion, but breaks in all other ways above, as well as introducing an obfuscating decimal in the release tag. I hope RH agrees to using A) or a variant thereof. In any case it would be beneficial if an "official" solution could be blessed, so that 3rd party repos don't have to reinvent their own versioning. Certainly many repos will start offering their packages (officially) after FC1 is (officially) released, so there are only a few days left ... In order to not molest users with forced downloads for reversioning rpms for older RHL releases, I would suggest to use B) in a transition phase for large rpms that do not need updating other than the reversioning. After some time B) will have been phased out. C) is not really an option. It will break more than it is intended to salvage. Also it would be nice to have rawhide versioning, e.g. immediately after a release update fedora-release to the next test release version or something below to indicate rawhide builds. Thank you for your time. -- Axel.Thimm(a)physik.fu-berlin.de

5 9

Warren's Package Naming Proposal - Revision 1
by Warren Togami 08 Nov '03

08 Nov '03

http://www.fedora.us/wiki/PackageNamingGuidelines The following is based upon current fedora.us package naming guidelines, quickly edited and dramatically simplified because fedora.redhat.com no longer needs many of fedora.us special considerations. The below proposal is ALMOST EXACTLY THE SAME as fedora.us current scheme except with the leading "0.fdr." removed from all %{release} tags. I would assert that fedora.us package naming scheme has demonstrated to be a great success, thus it should continued in fedora.redhat.com. The below scheme is also in-line with the common practices used by most of Red Hat's existing packages. This proposal is missing considerations for 3rd party repositories. Theoretically 3rd party repositories should no longer have a reason to publish the same %{name} of any packages that exist in FC or FE because changes should be incorporated upstream. There are however some cases like kde-redhat where this is not possible, so we really need to discuss possible solutions to this. Earlier we had discussed the possibility of simply adding a %{reptag} to the far right of %{release}. Fedora Package Naming Guidelines Warren's Proposal for fedora.redhat.com Revision 1 ================================ i. Introduction Goals for package naming guidelines ii. Terminology A. Package Name B. Version C. Release Tag 1. Release Prefix 2. Vepoch 3. Non-Numeric Version to Release 4. Dist tag 5. Special: Kernel modules 6. Special: Plugin, theme etc packages 7. Special: Minor Number i. Introduction =============== Goals for the Fedora Package Naming Guidelines * Easily understandable package naming policy * Indication of the original source version (end-user convenience) * Allow for a smooth upgrade path between multiple levels of testing branches and future distribution upgrades. This means E-V-R must never be exactly identical between distribution versions. * Minimize the chance of package conflicts for future Fedora distribution upgrades. ii. Terminology ============== name This is the "Name" field of RPM .spec files. version This is the "Version" field of RPM .spec files. release tag This is the "Release" field of RPM .spec files. dist tag This is a distribution tag indicating which RHL/FC distribution this package is intended for. This only occurs in cases where packages from different distributions are built from the same SRPM and patchlevel. vepoch This is our term for "version specific epoch", used in all packages as a simple means of ensuring upgrades by simple incrementing the leading number within the release tag. vepoch is otherwise known as "release number" or "patchlevel". Read C-2 for more information. E-V-R Abbreviation for epoch, version, and release. This is often referred to when talking about potential package upgrading problems. A. Package Name =============== Package name should preferably match the upstream tarball or project name from which this software came. In some cases this naming choice is more complicated. If this package has been packaged by other distributions/packagers (Mandrake, SuSE, Conectiva, PLD, PLF, FreshRPMS, etc.) in the past, then we should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision. Ultimately it is up to QA to decide upon the proper %{name} before publication. B. Version ========== If the version is only numbers, then these numbers can be put into the "version" field of the RPM .spec unchanged. If the version contains non-numeric characters, this creates several problems for RPM version comparison and a broken upgrade path. Example: foobar-1.2.3beta1.tar.gz foobar-1.2.3.tar.gz While the "1.2.3" version is newer than the 1.2.3beta1 version, RPM version comparison thinks the former is newer. Example: foobar-1.0a foobar-1.0b The "1.0b" version is higher than "1.0a", but all versions of RPM prior to rpm-4.2-0.55 are confused when it tries to compare letters. Whichever package is first in the comparison "wins", thus this becomes a two way upgrade problem. This a < b comparison works properly only in RH9 and higher. For simplicity, Fedora treats both pre-release and post-release non-numeric version cases the same, making the version purely numeric and moving the alphabetic part to the release tag. Take the numeric portion of the source version and make that the package version tag. Read C-3 for more details. C. Release Tag ============== The release tag of Fedora packages more complicated, so this is split into several parts. C-1. Release Prefix ------------------- No longer needed in fedora.redhat.com. C-2. Vepoch ----------- The leftmost leading number within the release tag is the "version specific epoch" or vepoch in Fedora. This number is incremented with every package update. The vepoch is otherwise known as the "release number" or "patchlevel". The key difference between the concept of "vepoch" and "patch level" is that everything to the right of the vepoch is PURELY INFORMATIONAL. The only time where it matters is to guarantee a different %{release} tag between two distribution versions. The vepoch is to be respected by Fedora Core/Extras/Alternatives/Legacy as canonical. Package updates in any repository should always check all other official repositories to be sure that the vepoch is always incremented and never matching an existing package. With most normal packages, vepoch is a single number starting at "1". Under the (C-3) non-numeric version case it is two numbers starting at "0.1" with the second number being the number to increment. Normal Package Example: foobar-1.2.3-1.src.rpm compiles to foobar-1.2.3-1.i386.rpm If this package is patched: foobar-1.2.3-2.i386.rpm foobar-1.2.3-3.i386.rpm C-3. Non-Numeric Version to Release ----------------------------------- As mentioned above in section B (Version) and C-2 (Vepoch), non-numeric versioned packages can be problematic so they must be treated with care. These are cases where the upstream version has letters rather than simple numbers in their version. Often they have tags like alpha, beta, rc, or letters like a and b denoting that it is a version before or after the number. Read section B to understand why we cannot simply put these letters into the version tag. Release Tag for Pre-Release Packages: 0.%{X}.%{alphatag} Release Tag for Non-Numeric Post-Release Packages: %{X}.%{alphatag} Where %{X} is the vepoch increment, and %{alphatag} is the string that came from the version. Example (pre-release): mozilla-1.4a.tar.gz from usptream is lower than mozilla-1.4.tar.gz the later "final" version thus mozilla-1.4-0.1.a Fedora package name Example (pre-release): alsa-lib-0.9.2beta1.tar.gz becomes alsa-lib-0.9.2-0.1.beta1 Example (post-release): gkrellm-2.1.7.tar.gz gkrellm-2.1.7a.tar.gz Quick bugfix release after 2.1.7 gkrellm-2.1.7-1.a Upgrade Path Example (mozilla): mozilla-1.4-0.1.a Patched mozilla-1.4-0.2.a Patched again mozilla-1.4-0.3.a Move to 1.4b mozilla-1.4-0.4.b Patched mozilla-1.4-0.5.b Move to 1.4 "final" version Notice that this becomes a normal C-2 case mozilla-1.4-1 Patched mozilla-1.4-2 Upgrade Path Example (alsa-lib): alsa-lib-0.9.2-0.1.beta1 Patched alsa-lib-0.9.2-0.2.beta1 Move to beta2 alsa-lib-0.9.2-0.3.beta2 Move to beta3 and simultaneously patch alsa-lib-0.9.2-0.4.beta3 Patched again alsa-lib-0.9.2-0.5.beta3 Move to rc1 alsa-lib-0.9.2-0.6.rc1 Move to rc2 alsa-lib-0.9.2-0.7.rc2 Move to "final" alsa-lib-0.9.2-1 Patched alsa-lib-0.9.2-2 C-4. Dist tag ------------- In cases where the same SRPM and patchlevel is used between two or more distributions supported by Fedora, a dist tag is appended to the end of the release tag defined in C-2 and C-3. The dist tags with the following examples appear to be only cosmetic, however the a different E-V-R is needed between distributions to ensure dist upgrading works fully in all corner cases. Dist Tag for Normal Packages: %{X}.%{disttag} Where %{X} is the vepoch and %{disttag} is a distribution tag from this table: 0.7.3 Red Hat Linux 7.3 0.8 Red Hat Linux 8 0.9 Red Hat Linux 9 1 Fedora Core 1 1.93 Fedora Core 1.93 beta 1.94 Fedora Core 1.94 beta 2 Fedora Core 2 beta Example: foobar-1.2.3-1_0.7.3.i386.rpm foobar-1.2.3-1_0.8.i386.rpm foobar-1.2.3-1_0.9.i386.rpm foobar-1.2.3-1_1.94.i386.rpm foobar-1.2.3-1_2.i386.rpm Upgrade Path Example (FC1 only shown): foobar-1.2.3-1_1.i386.rpm foobar-1.2.3-2_1.i386.rpm foobar-1.2.3-3_1.i386.rpm Dist Tag for Pre-Release Packages: %{X}.%{alphatag}.%{disttag} Where %{X} is the vepoch, %{alphatag} is the pre-release tag described in C-3, %{disttag} is a distribution tag described above. Example: alsa-lib-0.9.2-0.1.beta1_0.8.i386.rpm alsa-lib for RH 8.0 alsa-lib-0.9.2-0.1.beta1_1.i386.rpm alsa-lib for FC1 Upgrade Path Example (RH 7.3 only shown): alsa-lib-0.9.2-0.1.beta1_0.7.3 alsa-lib-0.9.2-0.2.beta1_0.7.3 alsa-lib-0.9.2-0.3.beta2_0.7.3 alsa-lib-0.9.2-0.4.beta3_0.7.3 alsa-lib-0.9.2-0.5.beta3_0.7.3 alsa-lib-0.9.2-0.6.rc1_0.7.3 alsa-lib-0.9.2-0.7.rc2_0.7.3 alsa-lib-0.9.2-1_0.7.3 alsa-lib-0.9.2-2_0.7.3 C-5. Special Case: Kernel modules --------------------------------- This section needs its own discussion due to changed provides within FC1's kernel, and the fact that older distributions are different. C-6. Plugin, theme etc packages ------------------------------- Packages that are plugins, themes or the like, ie. enhance other packages must be named <package-to-enhance>-<enhancement>. If the resulting name differs significantly from upstream naming, a Provides: <upstream-name> = %{epoch}:%{version}-%{release} must be added. For example: Upstream package name: modplug-xmms Fedora package name: xmms-modplug Provides: modplug-xmms = %{epoch}:%{version}-%{release} C-7. Minor Number ----------------------- Probably no longer needed at fedora.redhat.com.

12 25

Yum-able screen-4.0.1 test-only RPMS
by Lon Hohberger 07 Nov '03

07 Nov '03

Hi, I put RPMS of screen-4.0.1 on my people.redhat.com account. You can use yum: http://people.redhat.com/lhh/fedora Or, download the packages directly: http://people.redhat.com/lhh/fedora/screen-4.0.1-0.1.i386.rpm http://people.redhat.com/lhh/fedora/screen-4.0.1-0.1.src.rpm The major difference is screen's lack of needing backspace bindings. NOTE NOTE NOTE: If you test this package, you must also comment out the "stty erase `tput kbs`" line from your shell's rcfile. Tcsh users, I am told, do not need to do this. Additionally, you may have to remove the backspace key binding from /etc/screenrc or ~/.screenrc (If RPM saves your old configuration...) The goal here is to remove all of the workaround we put in to make screen work properly WRT backspace/del. In theory, 4.0.1 no longer needs them. -- Lon Hohberger Red Hat, Inc. --> http://www.redhat.com My Public Key --> http://people.redhat.com/lhh/pubkey.txt The views expressed in this electronic mail message are mine alone and do not necessarily reflect the views of Red Hat, Inc.

2 2

Self-Introduction: Logan Rathbone
by Logan Rathbone 05 Nov '03

05 Nov '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~Logan A. Rathbone~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~Mississauga, Ontario, Canada~~~~~~~~~~~~~~~ ~University student - 1st year of studies in Economics~ ~~~~~~~~~~~~~~~University of Toronto~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~My goals in the Fedora Project:~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There have been many myths surrounding Linux on the desktop. It is an extremely common perception of many people, namely those that have never parted from Microsoft's operating systems, that Linux is difficult to use. While many Linux users try day after day to dispell many of these myths, 99% of PCs are still running Windows. I believe that it is time for us to ask, "why?" Many Linux users today, especially those who are very experienced with Linux and computing in general, feel that the opinions of these users do not count. I believe that nothing could be farther from the truth. These users need to be convinced that the time for them to change their operating system is NOW. However, while Linux is an operating system that is so superior to Windows in so many ways, there are several issues that need to be ironed out. In the case of what was previously Red Hat Linux and is now the Fedora Project, I believe that the issue is that of software installation. Red Hat started to address this problem fairly recently with their up2date tool. While the tool itself is wonderful, it is just a tool (as are yum, apt, etc. as well.) I feel that what Fedora needs at this point (among other things, of course) is a strong package repository, like what users of Debian have already. I actually switched from Red Hat to Debian because of that at one point. However, I returned in the other direction as soon as I heard about the Red Hat-Fedora merger. I am _not_ saying Fedora needs to become Debian. Debian lacks the professionalism that has always been sought by Red Hat distributions of Linux. In other words, I feel that Fedora users should have the best of bo! th worlds -- a strong library (quality _and_ quantity) of software available, in the form of a yum repository (ie: rawhide) _and_ a professional, unique and sleek operating system that will make many home users of Windows take a run for their money. I am a very recent adopter of Linux -- I started in June 2003, just a few short months ago. I know what it's like to be a Windows user, and I know what kind of software home users want. That is why I feel that it is my _duty_ to be a packager of supplementary software for the Fedora Project. When Fedora users are browsing the internet or IRC and hear about a cool new software package XYZ, they should be able to type "yum install XYZ" and have that package on their machine, without so much as a fuss. But of course, I and the other packagers would take legal issues into mind and only package software that complies with the legal entities of the Fedora Project. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Historical Qualifications~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In truth, I have very few. But, one must start somewhere. I am quite heavily involved in certain aspects of the Ark Linux distribution (www.arklinux.org) and have done some minor package building (RPMs) as well as general community support. I believe that my one true qualification is the fact that I am still, at heart, a home PC user. I am not a power-user, I am not a programmer, and I am not by any means a developer. I am simply your average-Joe home computer user that knows how to build RPM packages. In the case of my role in this project, however, I feel that my lack of technical expertise can be seen as more of an asset and less a liability. Most Windows users that convert to Linux don't know about the 2 main desktop environments. They don't understand the concept of window managers, the kernel, bash and other shells, X, etc. To them, Linux is Linux is Linux; they want to try it because they've heard about how it is a more stable, more secure, and generally a be! tter computing environment than Windows. I understand this mentality (I was there just last June, remember?) and I will certainly take it into account when selecting and building packages. You should trust me for one reason, and for one reason only -- for the past months, I have been utterly compelled and even obsessed with the Linux operating system, and I have placed my entire trust in Linux and the Linux community. I have gone from distribution-to-distribution, each time more disappointed than the last. However, I have finally seen light at the end of the tunnel. That light is, of course, the Fedora Project. I hope dearly that I will be permitted to contribute to this wonderful project, Logan "Poprocks" Rathbone [logan@localhost logan]$ gpg --fingerprint BF86D3F4 pub 1024D/BF86D3F4 2003-10-30 Logan Rathbone (Poprocks) <poprocks(a)linux.net> Key fingerprint = AA14 D6F3 0F7B 650B 5E7C A588 33D8 77F7 BF86 D3F4 sub 2048g/296BEE8D 2003-10-30 [expires: 2008-10-28] _____________________________________________________________ Linux.Net -->Open Source to everyone Powered by Linare Corporation http://www.linare.com/

5 5

Run prelink and other stuff not in cron but when screensaver is active.
by Jaap A. Haitsma 04 Nov '03

04 Nov '03

I sometime get a bit frustrated that a cron job starts while I'm working. Wouldn't it be nicer that this stuff would run when I'm not doing any work. I.e. when the screensaver is active. Maybe as a minor enhancement when the screensaver is active and there is not a process asking for cpu power /disk access. Sometimes I'm running compiling jobs which take quite a while. Jaap

8 11

Packages RFC
by George Garvey 02 Nov '03

02 Nov '03

For my own purposes, I'm going to package: prcs qmail distcc gcc to mingw cross-compiler fltk I doubt qmail is of interest to Fedora, but what about the others? Want them passed on?

16 23

Enhanced Logrotate from Suse
by Keith Lofstrom 01 Nov '03

01 Nov '03

/usr/sbin/logrotate is the program that moves and renames files in /var/log. On Redhat systems, it typically does this by numbering and renumbering - messages becomes messages.1, .1 becomes .2, etc. This makes life difficult for rsync backups, which saves each copy of each renumbered file. Ruediger Oertel at Suse (ro(a)suse.de) has some patches that enhance the basic Redhat Logrotate with "dateext". This allows a dated extension rather than a numbered one, i.e. messages.29102003 . The old logfiles do not get renamed, just discarded after they get too old. This is a lot easier on rsync, and it also is easier to administer. Ruediger's patches do not change the current logrotate behavior, just adds the new features. His patch to logrotate 3.6.10 can be found at: ftp.suse.com/pub/people/ro/logrotate Suse has been making these patches to RH logrotate for years, and I've been running versions of their code for a few weeks while still using the old logrotate method for testing. It would be nice to fold this into the main line of fedora/redhat and eliminate a needless code fork. Who do I talk to in order to make this happen? Keith BTW, this is the third attempt at sending this, though perhaps the first clueful attempt ... :-) -- Keith Lofstrom keithl(a)ieee.org Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs

2 1

XFree86 & Neomagic: DRI missing?
by Patrick 01 Nov '03

01 Nov '03

Fully updated Fedora as of Oct 30, 23:15 CET. When I run glxgears it complains: Xlib: extensions "XFree86-DRI" missing on display ":0.0". I thought 3D hardware acceleration was supported on the Neomagic NM2200. Any ideas? TIA, Patrick

4 4

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