From marcdeslauriers at videotron.ca  Tue Mar  1 01:36:56 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Mon, 28 Feb 2005 20:36:56 -0500
Subject: Fedora Legacy Test Update Notification: php
Message-ID: <4223C738.5000307@videotron.ca>


The packages have been updated to add CAN-2004-1392 and another
unserialize function issue that doesn't have a CAN number.

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2344
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2344
2005-02-28
---------------------------------------------------------------------

Name        : php
Versions    : rh7.3: php-4.1.2-7.3.14.legacy
Versions    : rh9: php-4.2.2-17.10.legacy
Versions    : fc1: php-4.3.10-1.1.legacy
Summary     : The PHP HTML-embedded scripting language.
Description :
PHP is an HTML-embedded scripting language. PHP attempts to make it
easy for developers to write dynamically generated webpages. PHP also
offers built-in database integration for several commercial and
non-commercial database management systems, so writing a
database-enabled webpage with PHP is fairly simple. The most common
use of PHP coding is probably as a replacement for CGI scripts. The
mod_php module enables the Apache Web server to understand and process
the embedded PHP language in Web pages.

---------------------------------------------------------------------
Update Information:

Updated php packages that fix various security issues are now available.

PHP is an HTML-embedded scripting language commonly used with the Apache
HTTP Web server.

An information disclosure bug was discovered in the parsing of "GPC"
variables in PHP (query strings or cookies, and POST form data). If
particular scripts used the values of the GPC variables, portions of the
memory space of an httpd child process could be revealed to the client.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0958 to this issue.

A file access bug was discovered in the parsing of "multipart/form-data"
forms, used by PHP scripts which allow file uploads. In particular
configurations, some scripts could allow a malicious client to upload
files to an arbitrary directory where the "apache" user has write
access. The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CAN-2004-0959 to this issue.

Flaws were found in shmop_write, pack, and unpack PHP functions. These
functions are not normally passed user supplied data, so would require a
malicious PHP script to be exploited. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2004-1018 to
this issue.

Flaws including possible information disclosure, double free, and
negative reference index array underflow were found in the
deserialization code of PHP. PHP applications may use the unserialize
function on untrusted user data, which could allow a remote attacker to
gain access to memory or potentially execute arbitrary code. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-1019 to this issue.

A flaw in the exif extension of PHP was found which lead to a stack
overflow. An attacker could create a carefully crafted image file in
such a way that if parsed by a PHP script using the exif extension it
could cause a crash or potentially execute arbitrary code. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-1065 to this issue.

A flaw in the PHP cURL functions allows remote attackers to bypass the
open_basedir setting and read arbitrary files via a file: URL argument
to the curl_init function. The Common Vulnerabilities and Exposures
project (cve.mitre.org) has assigned the name CAN-2004-1392 to this
issue.

Users of PHP should upgrade to these updated packages, which contain
fixes for these issues.

---------------------------------------------------------------------
7.3 changelog:
* Sat Feb 26 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
4.1.2-7.3.14.legacy
- Added security patch for CAN-2004-1392

* Mon Jan 31 2005 John Dalbec <jpdalbec at ysu.edu> 4.1.2-7.3.13.legacy
- Fix typo in OpenPKG backport patch (filename -> filenamebuf)
- * Sun Jan 23 2005 Leonard den Ottolander <leonard * den ottolander nl> 
4.1.2-7.3.11.legacy
   - fix possible double-free in unserializer (CAN-2004-1019)
   - fix integer overflows in pack() (CAN-2004-1018, requires
     malicious script to exploit)
- Remove redundant CAN-2004-1018 sections from OpenPKG backport patch

* Wed Jan 05 2005 Pekka Savola <pekkas at netcore.fi> 4.1.2-6.3.12.legacy
- Use a more complete patch, some parts had been left off
   by accident.

* Mon Jan 03 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
4.1.2-7.3.11.legacy
- Added OpenPKG patch backport for CAN-2004-1018, CAN-2004-1019, 
CAN-2004-1063,
   CAN-2004-1064 and CAN-2004-1065

9 changelog:
* Sun Feb 27 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
4.2.2-17.10.legacy
- Rebuilt

* Sat Feb 26 2005 Pekka Savola <pekkas at netcore.fi> 4.2.2-17.9.legacy.3
- Fix CAN-2004-1392, from Ubuntu (#2344)

* Sat Feb 26 2005 Pekka Savola <pekkas at netcore.fi> 4.2.2-17.9.legacy.2
- a more complete patch of unserializer, overhaul it to 4.3.10 like RHEL3

* Wed Dec 22 2004 Pekka Savola <pekkas at netcore.fi> 4.2.2-17.9.legacy
- Replace the previous patches with a complete OpenPKG backport, fixing the
issues (and more of them) more extensively.

* Tue Dec 21 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
4.2.2-17.8.legacy
- Added security patches for CAN-2004-1019 and CAN-2004-1065

fc1 changelog:
* Sat Feb 26 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
4.3.10-1.1.legacy
- Updated to 4.3.10 to completely fix security issues
- Added patch for CAN-2004-1392
- revert use of RTLD_GLOBAL in dlopen() calls (rh#127518)
- add another FD_SETSIZE workaround (rh#125258)
- revert upstream default php.ini changes since 4.3.6
- add libgd namespace fixes (rh#124530)

* Mon Feb 21 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
4.3.8-1.5.legacy
- Added missing gnupg BuildRequires

* Fri Feb 11 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
4.3.8-1.4.legacy
- Added missing sendmail, w3c-libwww-devel and flex BuildRequires

* Mon Jan 03 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
4.3.8-1.3.legacy
- Added patches for CAN-2004-0958 and CAN-2004-0959

* Tue Dec 21 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
4.3.8-1.2.legacy
- Added OpenPKG patch for CAN-2004-1018, CAN-2004-1019, CAN-2004-1063,
   CAN-2004-1064 and CAN-2004-1065

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

b88c0d83d4a9aeb974a6ee54ce66a27ecefa392a 
redhat/7.3/updates-testing/i386/php-4.1.2-7.3.14.legacy.i386.rpm
48fd82779841a679e84e93f8ef1b612965acb342 
redhat/7.3/updates-testing/i386/php-devel-4.1.2-7.3.14.legacy.i386.rpm
573aad4bab9f4f4399aedea743999020b3246614 
redhat/7.3/updates-testing/i386/php-imap-4.1.2-7.3.14.legacy.i386.rpm
1a18d347e68013d29586f6a8db8283bdf7f6ff66 
redhat/7.3/updates-testing/i386/php-ldap-4.1.2-7.3.14.legacy.i386.rpm
2a84f086225993aeccb0dfe2dd21ca8fcd78f26e 
redhat/7.3/updates-testing/i386/php-manual-4.1.2-7.3.14.legacy.i386.rpm
d856fcc947e9386db2116f581cd0faf9efa5cf39 
redhat/7.3/updates-testing/i386/php-mysql-4.1.2-7.3.14.legacy.i386.rpm
5621afdf4dd720ca24b489ccd115f6ead0b5343d 
redhat/7.3/updates-testing/i386/php-odbc-4.1.2-7.3.14.legacy.i386.rpm
41bc8b4cf9c357c8030c09c4454c0e2173e0c523 
redhat/7.3/updates-testing/i386/php-pgsql-4.1.2-7.3.14.legacy.i386.rpm
42bec2bd2e0f98fed8e01e82eef7a845c37020d2 
redhat/7.3/updates-testing/i386/php-snmp-4.1.2-7.3.14.legacy.i386.rpm
8c6cf550cb6b6f4a75742120f56c6b77ff3d49e4 
redhat/7.3/updates-testing/SRPMS/php-4.1.2-7.3.14.legacy.src.rpm
7fdeae44517dc2ef29fbb0480f9046fc6dadc8e3 
redhat/9/updates-testing/i386/php-4.2.2-17.10.legacy.i386.rpm
e9244f6732eb2c83128d91e57439e7cc36c3c982 
redhat/9/updates-testing/i386/php-devel-4.2.2-17.10.legacy.i386.rpm
054f45490faa2d6bc641b22bade7f3db92d07cde 
redhat/9/updates-testing/i386/php-imap-4.2.2-17.10.legacy.i386.rpm
76ade25210bb37b4757b535d48de39e8c2dec622 
redhat/9/updates-testing/i386/php-ldap-4.2.2-17.10.legacy.i386.rpm
53d0e83c9b10e9d84e0150c9dbdb70f4df3a930a 
redhat/9/updates-testing/i386/php-manual-4.2.2-17.10.legacy.i386.rpm
81ac7899358407bbd2c38baf7547136413970372 
redhat/9/updates-testing/i386/php-mysql-4.2.2-17.10.legacy.i386.rpm
cceed4ce195fa9ff864eb6561b7bfb6297eb5bff 
redhat/9/updates-testing/i386/php-odbc-4.2.2-17.10.legacy.i386.rpm
839c239b525265df7abaeac1c5f0c08092c74944 
redhat/9/updates-testing/i386/php-pgsql-4.2.2-17.10.legacy.i386.rpm
b1cd0eb61b109a2b5da15791b8781806b44c7efc 
redhat/9/updates-testing/i386/php-snmp-4.2.2-17.10.legacy.i386.rpm
fe9529ca28ff2663a9b520fd5e774cf931e0b135 
redhat/9/updates-testing/SRPMS/php-4.2.2-17.10.legacy.src.rpm
dd0daa7c3d6b4f491605e698c39cb451edff50ba 
fedora/1/updates-testing/i386/php-4.3.10-1.1.legacy.i386.rpm
c07635eca5d2ce4f1972c5faf3e14f4c00a19f2d 
fedora/1/updates-testing/i386/php-devel-4.3.10-1.1.legacy.i386.rpm
2658aabd4ebe409b0b9532baf0894abfe15c0f38 
fedora/1/updates-testing/i386/php-domxml-4.3.10-1.1.legacy.i386.rpm
b38d0ef81f4ccc1ef914bdeb4077461d4dba2d7b 
fedora/1/updates-testing/i386/php-imap-4.3.10-1.1.legacy.i386.rpm
e8d7d69f35641f915edba0eb9c5915db60e318d5 
fedora/1/updates-testing/i386/php-ldap-4.3.10-1.1.legacy.i386.rpm
f9a609b45b56e028080246ea7df8a53d1e0c33b7 
fedora/1/updates-testing/i386/php-mbstring-4.3.10-1.1.legacy.i386.rpm
f34d4ab35fc29149a8c8f84140940c9470356415 
fedora/1/updates-testing/i386/php-mysql-4.3.10-1.1.legacy.i386.rpm
71c362c35b2368348b56d8cd5f7c03812f7b7aa2 
fedora/1/updates-testing/i386/php-odbc-4.3.10-1.1.legacy.i386.rpm
de668bafb64e2f7cb8e3d1add11e8037159ce90d 
fedora/1/updates-testing/i386/php-pgsql-4.3.10-1.1.legacy.i386.rpm
d2bc37081e2633c0cbd721b24cbbeadffc0196be 
fedora/1/updates-testing/i386/php-snmp-4.3.10-1.1.legacy.i386.rpm
1538dab5f7b07a29191f459441478a4c9cc2c11e 
fedora/1/updates-testing/i386/php-xmlrpc-4.3.10-1.1.legacy.i386.rpm
125b673172ebeb9cf0bdefe5adc0060ae10d3c9d 
fedora/1/updates-testing/SRPMS/php-4.3.10-1.1.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050228/404e988d/attachment.sig>

From marcdeslauriers at videotron.ca  Tue Mar  1 01:37:36 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Mon, 28 Feb 2005 20:37:36 -0500
Subject: Fedora Legacy Test Update Notification: kdelibs, kdebase
Message-ID: <4223C760.4040602@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2008
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2008
2005-02-28
---------------------------------------------------------------------

Name        : kdelibs and kdebase
Versions    : rh7.3: kdelibs-3.0.5a-0.73.6.legacy
Versions    : rh9: kdelibs-3.1-17.legacy
Versions    : fc1: kdelibs-3.1.4-9.legacy
Summary     : Libraries for the K Desktop Environment.
Description :
KDE Libraries include: kdecore (KDE core library), kdeui (user
interface), kfm (file manager), khtmlw (HTML widget), kio
(Input/Output, networking), kspell (spelling checker), jscript
(javascript), kab (addressbook), kimgio (image manipulation).

---------------------------------------------------------------------
Update Information:

Updated kdelib and kdebase packages that resolve several security issues
are now available.

The kdelibs packages include libraries for the K Desktop Environment.
The kdebase packages include core applications for the K Desktop
Environment.

Flaws have been found in the cookie path handling between a number of
Web browsers and servers. The HTTP cookie standard allows a Web server
supplying a cookie to a client to specify a subset of URLs on the origin
server to which the cookie applies. Web servers such as Apache do not
filter returned cookies and assume that the client will only send back
cookies for requests that fall within the server-supplied subset of
URLs. However, by supplying URLs that use path traversal (/../) and
character encoding, it is possible to fool many browsers into sending a
cookie to a path outside of the originally-specified subset. The Common
Vulnerabilities and Exposures project has assigned the name
CAN-2003-0592 to this issue.

iDEFENSE identified a vulnerability in the Opera web browser that could
allow remote attackers to create or truncate arbitrary files. The KDE
team has found two similar vulnerabilities that also exist in KDE. A
flaw in the telnet URI handler may allow options to be passed to the
telnet program, resulting in creation or replacement of files. An
attacker could create a carefully crafted link such that when opened by
a victim it creates or overwrites a file with the victim's permissions.
A flaw in the mailto URI handler may allow options to be passed to the
kmail program. These options could cause kmail to write to the file
system or to run on a remote X display. An attacker could create a
carefully crafted link in such a way that access may be obtained to run
arbitrary code as the victim. The Common Vulnerabilities and Exposures
project (cve.mitre.org) has assigned the name CAN-2004-0411 to these
issues.

Andrew Tuitt reported that versions of KDE up to and including 3.2.3
create temporary directories with predictable names. A local attacker
could prevent KDE applications from functioning correctly, or overwrite
files owned by other users by creating malicious symlinks. The Common
Vulnerabilities and Exposures project has assigned the name
CAN-2004-0689 to this issue.

WESTPOINT internet reconnaissance services has discovered that the KDE
web browser Konqueror allows websites to set cookies for certain country
specific secondary top level domains. An attacker within one of the
affected domains could construct a cookie which would be sent to all
other websites within the domain leading to a session fixation attack.
This issue does not affect popular domains such as .co.uk, .co.in, or
.com. The Common Vulnerabilities and Exposures project has assigned the
name CAN-2004-0721 to this issue.

A frame injection spoofing vulnerability has been discovered in the
Konqueror web browser. This issue could allow a malicious website to
show arbitrary content in a named frame of a different browser window.
The Common Vulnerabilities and Exposures project has assigned the name
CAN-2004-0746 to this issue.

Secunia Research discovered a window injection spoofing vulnerability
affecting the Konqueror web browser. This issue could allow a malicious
website to show arbitrary content in a different browser window. The
Common Vulnerabilities and Exposures project has assigned the name
CAN-2004-1158 to this issue.

A bug was discovered in the way kioslave handles URL-encoded newline
(%0a) characters before the FTP command. It is possible that a specially
crafted URL could be used to execute any ftp command on a remote server,
or potentially send unsolicited email. The Common Vulnerabilities and
Exposures project has assigned the name CAN-2004-1165 to this issue.

All users of KDE are advised to upgrade to this updated packages, which
contain backported patches to correct these issues.

---------------------------------------------------------------------
Changelogs

rh73 kdelibs:
* Wed Feb 16 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.0.5a-0.73.6.legacy
- CAN-2004-1158 and CAN-2004-1165 security patches

* Thu Sep 09 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.0.5a-0.73.5.legacy
- CAN-2004-0689, CAN-2004-0721, CAN-2004-0746 security patches

* Tue Jun 08 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.0.5a-0.73.4.legacy
- CAN-2004-0411 security patch
- (KDE Telnet URI Handler File Vulnerability)
- (Vulnerability in the mailto handler)

* Thu Mar 11 2004 Michael Schwendt <mschwendt[AT]users.sf.net> 
6:3.0.5a-0.73.3.legacy
- Backport RHL9 kdelibs-3.1-kcookiejar.patch to KDE 3.0.5a and Qt 3.0.x
   to fix CAN-2003-0592.
- Add a bunch of build requirements.

rh73 kdebase:
* Sat Feb 26 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.0.5a-0.73.7.legacy
- Added missing autoconf253, automake, libpng-devel, zlib-devel
   lm_sensors-devel, libvorbis-devel, openldap-devel, gettext
   freetype-devel, bzip2-devel and pam-devel to BuildPrereq

* Wed Feb 16 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.0.5a-0.73.6.legacy
- new security patch, CAN-2004-1158

* Thu Sep 09 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.0.5a-0.73.5.legacy
- new security patch, CAN-2004-0721

rh9 kdelibs:
* Sun Feb 27 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.1-17.legacy
- Added missing autoconf, automake, libpng-devel, libvorbis-devel
   desktop-file-utils, libart_lgpl-devel, bzip2-devel, libjpeg-devel
   openldap-devel, libtiff-devel and XFree86-devel BuilPrereq

* Wed Feb 16 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.1-16.legacy
- CAN-2004-1158 and CAN-2004-1165 security patches

* Thu Sep 09 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.1-15.legacy
- CAN-2004-0689, CAN-2004-0721, CAN-2004-0746 security patches

* Tue Jun 08 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.1-14.legacy
- CAN-2004-0411 security patch
- (KDE Telnet URI Handler File Vulnerability)
- (Vulnerability in the mailto handler)

rh9 kdebase:
* Sun Feb 27 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.1-18.legacy
- Added autoconf, automake15, libpng-devel, zlib-devel, lm_sensors-devel
   libvorbis-devel, openldap-devel, gettext, freetype-devel, audiofile-devel
   bzip2-devel, libart_lgpl-devel, libjpeg-devel  and pam-devel to 
BuildPrereq

* Thu Feb 17 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.1-17.legacy
- new security patch, CAN-2004-1158

* Thu Sep 09 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.1-16.legacy
- new security patch, CAN-2004-0721

fc1 kdelibs:
* Sun Feb 27 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.1.4-9.legacy
- Added autoconf, automake, XFree86-devel, libpng-devel, libvorbis-devel
   openldap-devel and libtiff-devel BuildPrereq

* Thu Feb 17 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.1.4-8.legacy
- Added security fixes for CAN-2004-1158 and CAN-2004-1165

fc1 kdebase:
* Sun Feb 27 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.1.4-9.legacy
- Added autoconf, automake15, libpng-devel, zlib-devel, lm_sensors-devel
   libvorbis-devel, openldap-devel, gettext, freetype-devel
   bzip2-devel, pam-devel, libart_lgpl-devel, audiofile-devel
   XFree86-devel, utempter and libjpeg-devel to BuildPrereq

* Thu Feb 17 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
6:3.1.4-8.legacy
- Added security patch for CAN-2004-1158

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
ab6411334132d5802fc3ee5f2fe84f093e4bc2e7 
redhat/7.3/updates-testing/i386/kdebase-3.0.5a-0.73.7.legacy.i386.rpm
56c46a2228202188e3ed7568d920026271c7b50b 
redhat/7.3/updates-testing/i386/kdebase-devel-3.0.5a-0.73.7.legacy.i386.rpm
150f547193e5c29da348580d5fbd3a073f9ef10e 
redhat/7.3/updates-testing/i386/kdelibs-3.0.5a-0.73.6.legacy.i386.rpm
018101a1b09d9e8f1ce5aef49186385ee5822eaf 
redhat/7.3/updates-testing/i386/kdelibs-devel-3.0.5a-0.73.6.legacy.i386.rpm
5cd53bb265cb29964d1d52680846296eaa34aa5e 
redhat/7.3/updates-testing/SRPMS/kdebase-3.0.5a-0.73.7.legacy.src.rpm
aac6a1b078750398b5636e26890d37eeaba15d07 
redhat/7.3/updates-testing/SRPMS/kdelibs-3.0.5a-0.73.6.legacy.src.rpm

rh9:
89ec164225d93ec6572d40f843c8ffed6e0b454b 
redhat/9/updates-testing/i386/kdebase-3.1-18.legacy.i386.rpm
a7e702304cc599eba38bd232ab216b2f11c04b03 
redhat/9/updates-testing/i386/kdebase-devel-3.1-18.legacy.i386.rpm
43952098114d6f1de023ad02051850d1e62a843b 
redhat/9/updates-testing/i386/kdelibs-3.1-17.legacy.i386.rpm
bfc0d2fc7e80c57a5306aac818cd75f073b114bd 
redhat/9/updates-testing/i386/kdelibs-devel-3.1-17.legacy.i386.rpm
937fc96d039dd3eb43a4acc975545b954112e3d5 
redhat/9/updates-testing/SRPMS/kdebase-3.1-18.legacy.src.rpm
2afbef59e60e63906b9ee20a57dccf438f667dcc 
redhat/9/updates-testing/SRPMS/kdelibs-3.1-17.legacy.src.rpm

fc1:
c9bb19c3b14d0307048d6963fd943a558b6beace 
fedora/1/updates-testing/i386/kdebase-3.1.4-9.legacy.i386.rpm
229ea248850a2bc07f3ea50f6a26932ba019aa93 
fedora/1/updates-testing/i386/kdebase-devel-3.1.4-9.legacy.i386.rpm
a9778ed5012ffbe9d9453e589ab04db5531e3918 
fedora/1/updates-testing/i386/kdelibs-3.1.4-9.legacy.i386.rpm
fbb005803701315f6d5932967f7e9152eb2365f0 
fedora/1/updates-testing/i386/kdelibs-devel-3.1.4-9.legacy.i386.rpm
3cdb52e7b0fd6fc444a7cea58034db5dcdbc9f99 
fedora/1/updates-testing/SRPMS/kdebase-3.1.4-9.legacy.src.rpm
0d896b24d8d88e072e7b46d1cf1ba9733b78b42a 
fedora/1/updates-testing/SRPMS/kdelibs-3.1.4-9.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050228/f64b5c29/attachment.sig>

From marcdeslauriers at videotron.ca  Tue Mar  1 01:38:22 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Mon, 28 Feb 2005 20:38:22 -0500
Subject: yum packages for rh9 available
Message-ID: <4223C78E.2060208@videotron.ca>

We now have pre-configured Fedora Legacy yum packages for rh9 available.

They can be downloaded from: http://download.fedoralegacy.org

8ffb527eccf987db9c211472d87d2284ea100aa3 
redhat/9/legacy-utils/i386/yum-2.0.5-0.9.2.legacy.noarch.rpm
c958f35411f12fccbaa623960478e11e94e2cf52 
redhat/9/legacy-utils/SRPMS/yum-2.0.5-0.9.2.legacy.src.rpm

If there are any issues with these packages, please add comments to the
following bugzilla report:

https://bugzilla.fedora.us/show_bug.cgi?id=1604

Thanks.

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050228/34bca206/attachment.sig>

From rostetter at mail.utexas.edu  Tue Mar  1 06:17:54 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue,  1 Mar 2005 00:17:54 -0600
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <Pine.LNX.4.61.0502251543440.31566@netcore.fi>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109336135.14050.1.camel@mdlinux>
	<Pine.LNX.4.61.0502251543440.31566@netcore.fi>
Message-ID: <1109657874.bd201ca708ff7@mail.ph.utexas.edu>

Quoting Pekka Savola <pekkas at netcore.fi>:

> This should _really_ be done by e.g.,
>   - having a script automatically demultiplex these messages from
> fedora-devel-list

Such a script exists.  It just isn't automatted.  Would be fairly easy
to do in theory.  Just subscribe an account to the list, run it through
something like procmail to process it and do a CVS checkin of the results,
and have an automated web site update from the CVS on a regular basis.

>   - requiring that the announce message that is sent out is also copied
> on the web server, from which the list of advisories is created
> immediately, or

The list (web page) you see is generated (via php) at request time.

>   - not provide any list at all, just point to the list archives for
> the advisories

This would also be possible in theory.  But it isn't as flexible as
the current message, at least in theory.  We're not using much of the
flexibility in the current method, but it is there (waiting for us to
want to use it).

> Manually updating seems to be a waste of energy, error prone, and
> incurs unnecessary delays.

Well, not sure about the first two, but it surely does incur delays.

> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
> 


-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Tue Mar  1 06:19:47 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue,  1 Mar 2005 00:19:47 -0600
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <1109354633.28467.74.camel@jkeating2.hq.pogolinux.com>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109336135.14050.1.camel@mdlinux>
	<Pine.LNX.4.61.0502251543440.31566@netcore.fi>
	<1109354633.28467.74.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1109657987.99265e6710155@mail.ph.utexas.edu>

Quoting Jesse Keating <jkeating at j2solutions.net>:

> Are you offering to code us up something that does this?  Currently we
> are spending our efforts on getting packages out, moving to RH bugzilla,
> and other higher level things which are of more importance.

The code is mostly there, and what isn't is pretty trivial.  We just need
permission to implement it, or someone who will implement it.  And for
servers to stabilize, etc. perhaps...
 
> --
> Jesse Keating RHCE      (geek.j2solutions.net)
> Fedora Legacy Team      (www.fedoralegacy.org)
> GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
> 
> Was I helpful?  Let others know:
>  http://svcs.affero.net/rm.php?r=jkeating
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
> 


-- 
Eric Rostetter



From jkeating at j2solutions.net  Tue Mar  1 06:26:17 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 28 Feb 2005 22:26:17 -0800
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <1109657987.99265e6710155@mail.ph.utexas.edu>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109336135.14050.1.camel@mdlinux>
	<Pine.LNX.4.61.0502251543440.31566@netcore.fi>
	<1109354633.28467.74.camel@jkeating2.hq.pogolinux.com>
	<1109657987.99265e6710155@mail.ph.utexas.edu>
Message-ID: <1109658377.13489.11.camel@localhost.localdomain>

On Tue, 2005-03-01 at 00:19 -0600, Eric Rostetter wrote:
> 
> The code is mostly there, and what isn't is pretty trivial.  We just
> need
> permission to implement it, or someone who will implement it.  And for
> servers to stabilize, etc. perhaps...

Now that I think back to our earlier conversations, i think the idea was
to modify the python tool that the builders use to generate the mail in
the first place to dump out a file that could be checked into the
webcvs, so that a regular scheduled web CVS checkout would snag the
update.  I haven't done anything in this area yet, but I'm still
thinking on it (:

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050228/577bab44/attachment.sig>

From deisenst at gtw.net  Tue Mar  1 10:59:43 2005
From: deisenst at gtw.net (David Eisenstein)
Date: Tue, 1 Mar 2005 04:59:43 -0600 (CST)
Subject: updated 'tree' on download.fedoralegacy.org
In-Reply-To: <1109448134.3258.66.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.44.0503010453310.3491-100000@twinkfed.homedns.org>

On Sat, 26 Feb 2005, Jesse Keating wrote:

> On Sat, 2005-02-26 at 12:57 +0200, Pekka Savola wrote:
> > It seems that the file http://download.fedoralegacy.org/tree has not 
> > been updated since the start of December or so.
> > 
> > This was probably due to the server move/crash.
> > 
> > Could this be re-added to cron (e.g., a daily or weekly run) -- the 
> > file is very useful for me to check which versions which RHL/FC 
> > versions have of a particular package..
> > 
> 
> oh, whoops!  That file was a test run to see if people liked the
> generated output.  Given that it doesn't use full paths, none of the
> packages are 'clickable' and some people didn't like that.  I'll re-add
> this to my to-do list of generating this file in an automated way w/
> clickable files.
> 

Jesse -- Why not make this file a simple ls-lR file?  Then you can gzip or
bzip2 it and it will likely use no more than 300-400kB.  And it makes it
much more usable to people who use the Virtual Filesystem of the Midnight
Commander.  Programming an "ls -lR" in a cron script is simple!  :-)

Speaking of Midnight Commander, there are packages out there in Bugzilla
2405 awaiting QA (hint, hint).  :-)  We need publish votes for FC1, RH9
and RH7.3.

		-David



From dom at earth.li  Tue Mar  1 11:50:12 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Tue, 1 Mar 2005 11:50:12 +0000
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <1109658377.13489.11.camel@localhost.localdomain>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109336135.14050.1.camel@mdlinux>
	<Pine.LNX.4.61.0502251543440.31566@netcore.fi>
	<1109354633.28467.74.camel@jkeating2.hq.pogolinux.com>
	<1109657987.99265e6710155@mail.ph.utexas.edu>
	<1109658377.13489.11.camel@localhost.localdomain>
Message-ID: <20050301115012.GA987@tirian.magd.ox.ac.uk>

On Mon, Feb 28, 2005 at 10:26:17PM -0800, Jesse Keating wrote:

> Now that I think back to our earlier conversations, i think the idea was
> to modify the python tool that the builders use to generate the mail in
> the first place to dump out a file that could be checked into the
> webcvs, so that a regular scheduled web CVS checkout would snag the
> update.  I haven't done anything in this area yet, but I'm still
> thinking on it (:

I'm generating the advisories manually; dunno about Marc. All tools
gratefully received :)

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



From marcdeslauriers at videotron.ca  Tue Mar  1 13:02:53 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Tue, 01 Mar 2005 08:02:53 -0500
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <20050301115012.GA987@tirian.magd.ox.ac.uk>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109336135.14050.1.camel@mdlinux>
	<Pine.LNX.4.61.0502251543440.31566@netcore.fi>
	<1109354633.28467.74.camel@jkeating2.hq.pogolinux.com>
	<1109657987.99265e6710155@mail.ph.utexas.edu>
	<1109658377.13489.11.camel@localhost.localdomain>
	<20050301115012.GA987@tirian.magd.ox.ac.uk>
Message-ID: <1109682173.2010.0.camel@mdlinux>

On Tue, 2005-03-01 at 11:50 +0000, Dominic Hargreaves wrote:
> On Mon, Feb 28, 2005 at 10:26:17PM -0800, Jesse Keating wrote:
> 
> > Now that I think back to our earlier conversations, i think the idea was
> > to modify the python tool that the builders use to generate the mail in
> > the first place to dump out a file that could be checked into the
> > webcvs, so that a regular scheduled web CVS checkout would snag the
> > update.  I haven't done anything in this area yet, but I'm still
> > thinking on it (:
> 
> I'm generating the advisories manually; dunno about Marc. All tools
> gratefully received :)
> 

I'm generating them manually also...

Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050301/1401da4a/attachment.sig>

From marcdeslauriers at videotron.ca  Tue Mar  1 13:05:12 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Tue, 01 Mar 2005 08:05:12 -0500
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <1109657874.bd201ca708ff7@mail.ph.utexas.edu>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109336135.14050.1.camel@mdlinux>
	<Pine.LNX.4.61.0502251543440.31566@netcore.fi>
	<1109657874.bd201ca708ff7@mail.ph.utexas.edu>
Message-ID: <1109682312.2010.4.camel@mdlinux>

On Tue, 2005-03-01 at 00:17 -0600, Eric Rostetter wrote:
> Quoting Pekka Savola <pekkas at netcore.fi>:
> 
> > This should _really_ be done by e.g.,
> >   - having a script automatically demultiplex these messages from
> > fedora-devel-list
> 
> Such a script exists.  It just isn't automatted.  Would be fairly easy
> to do in theory.  Just subscribe an account to the list, run it through
> something like procmail to process it and do a CVS checkin of the results,
> and have an automated web site update from the CVS on a regular basis.

It should NOT be automated. Malicious people would be tempted to sent
out fake advisories to get them automatically published to the web.
Heck, they could even embed some php in them to try and compromise the
server.

A manual yes/no is mandatory IMHO.

Marc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050301/043fb6f8/attachment.sig>

From jkeating at j2solutions.net  Tue Mar  1 15:19:51 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 01 Mar 2005 07:19:51 -0800
Subject: updated 'tree' on download.fedoralegacy.org
In-Reply-To: <Pine.LNX.4.44.0503010453310.3491-100000@twinkfed.homedns.org>
References: <Pine.LNX.4.44.0503010453310.3491-100000@twinkfed.homedns.org>
Message-ID: <1109690391.13489.12.camel@localhost.localdomain>

On Tue, 2005-03-01 at 04:59 -0600, David Eisenstein wrote:
> 
> Jesse -- Why not make this file a simple ls-lR file?  Then you can
> gzip or
> bzip2 it and it will likely use no more than 300-400kB.  And it makes
> it
> much more usable to people who use the Virtual Filesystem of the
> Midnight
> Commander.  Programming an "ls -lR" in a cron script is simple!  :-)

ls -lR doesn't generate clickable links.  However find . -print does.
Still toying with ideas.

> Speaking of Midnight Commander, there are packages out there in
> Bugzilla
> 2405 awaiting QA (hint, hint).  :-)  We need publish votes for FC1,
> RH9
> and RH7.3.
-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050301/160c6ef6/attachment.sig>

From dom at earth.li  Tue Mar  1 15:25:44 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Tue, 1 Mar 2005 15:25:44 +0000
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <1109682312.2010.4.camel@mdlinux>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109336135.14050.1.camel@mdlinux>
	<Pine.LNX.4.61.0502251543440.31566@netcore.fi>
	<1109657874.bd201ca708ff7@mail.ph.utexas.edu>
	<1109682312.2010.4.camel@mdlinux>
Message-ID: <20050301152544.GB987@tirian.magd.ox.ac.uk>

On Tue, Mar 01, 2005 at 08:05:12AM -0500, Marc Deslauriers wrote:

> It should NOT be automated. Malicious people would be tempted to sent
> out fake advisories to get them automatically published to the web.
> Heck, they could even embed some php in them to try and compromise the
> server.
> 
> A manual yes/no is mandatory IMHO.

Well, gpg verify from a known builder of updates. But yes, I agree.
It would be nice if the known builders were able to publish to the web
site and push package updates to the download server, too, of course ;)

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



From guallar at easternrad.com  Tue Mar  1 16:09:44 2005
From: guallar at easternrad.com (Josep L. Guallar-Esteve)
Date: Tue, 1 Mar 2005 11:09:44 -0500
Subject: updated 'tree' on download.fedoralegacy.org
In-Reply-To: <1109690391.13489.12.camel@localhost.localdomain>
References: <Pine.LNX.4.44.0503010453310.3491-100000@twinkfed.homedns.org>
	<1109690391.13489.12.camel@localhost.localdomain>
Message-ID: <200503011109.47431.guallar@easternrad.com>

On Tuesday 01 March 2005 10:19, Jesse Keating wrote:
> ls -lR doesn't generate clickable links. ?However find . -print does.
> Still toying with ideas.

Try something like this:

echo "<html><body><ul>" > index.html && ls *.rpm |  grep -v index.html | awk 
'{print "<li><a href=\""$1"\">" $1"</a></li>"} '   >> index.html && echo 
"</ul></body></html>" >> index.html


Regards,
Josep
-- 
Josep L. Guallar-Esteve		Eastern Radiologists, Inc.
Systems and PACS Administration  http://www.easternrad.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050301/05e03dae/attachment.sig>

From rostetter at mail.utexas.edu  Tue Mar  1 16:11:26 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue,  1 Mar 2005 10:11:26 -0600
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <20050301115012.GA987@tirian.magd.ox.ac.uk>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109336135.14050.1.camel@mdlinux>
	<Pine.LNX.4.61.0502251543440.31566@netcore.fi>
	<1109354633.28467.74.camel@jkeating2.hq.pogolinux.com>
	<1109657987.99265e6710155@mail.ph.utexas.edu>
	<1109658377.13489.11.camel@localhost.localdomain>
	<20050301115012.GA987@tirian.magd.ox.ac.uk>
Message-ID: <1109693486.5888938fbbbc3@mail.ph.utexas.edu>

Quoting Dominic Hargreaves <dom at earth.li>:

> On Mon, Feb 28, 2005 at 10:26:17PM -0800, Jesse Keating wrote:
> 
> > Now that I think back to our earlier conversations, i think the idea was
> > to modify the python tool that the builders use to generate the mail in
> > the first place to dump out a file that could be checked into the
> > webcvs, so that a regular scheduled web CVS checkout would snag the
> > update.  I haven't done anything in this area yet, but I'm still
> > thinking on it (:
> 
> I'm generating the advisories manually; dunno about Marc. All tools
> gratefully received :)

One of the neat features of that is that all the advisories are different
formats (different MIME formats, different signatures, etc).  Makes parsing
them more fun. :)

The things I'd like to see, and have been on my TODO list since day one, are:

* Have CVS commits e-mailed to a list of CVS/web people.
* Have an automatted system for updating the web site from CVS (cron, etc).

So far, neither has been a big issue, since I'm the only one working on 
the web site, etc.  But if any one else ever does volunteer to work on the
web site, those changes will be near critical to making things work well,
IMHO.

I've volunteered at one time or another to help setup (or to setup) both
those.

I'm not complaining, so much as just trying to state on the record what
I've asked for and volunteered for in the past.

One problem with an automatted system for the advisories is that the
advisories are not uniform when e-mailed out.  So there is always a 
chance, in particular when a new person joins the team of people sending
out advisories, that a message won't get converted to html correctly.
So even in an automatted system, we'd need to keep on eye on the output
and correct any errors that might appear.  Not that this should stop us
from implementing such a system, just trying to point out that even a
good automatted system will require monitoring and tweaking.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Tue Mar  1 16:17:56 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue,  1 Mar 2005 10:17:56 -0600
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <1109682312.2010.4.camel@mdlinux>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109336135.14050.1.camel@mdlinux>
	<Pine.LNX.4.61.0502251543440.31566@netcore.fi>
	<1109657874.bd201ca708ff7@mail.ph.utexas.edu>
	<1109682312.2010.4.camel@mdlinux>
Message-ID: <1109693876.6a9cf7e603442@mail.ph.utexas.edu>

Quoting Marc Deslauriers <marcdeslauriers at videotron.ca>:

> It should NOT be automated. Malicious people would be tempted to sent
> out fake advisories to get them automatically published to the web.

If done by the publisher, then this wouldn't be a problem.  If done
via an e-mail subscription, then this is true and a valid issue.

> A manual yes/no is mandatory IMHO.

Well, that's fine, and the way we've been doing it.  The problem is, if
I'm the only one doing it, and I leave for a 2 week vacation, what happens?
So far, what happens is this discussion, which is a great start!

I had not thought of the security concerns before.  I see this as being
pretty much a show stopper for the automatted e-mail approach.  It pushes
it back towards Jesse's idea of the creator of the advisory doing a direct
cvs checkin or something similar.

> Marc.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Tue Mar  1 17:02:02 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue,  1 Mar 2005 11:02:02 -0600
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <20050301152544.GB987@tirian.magd.ox.ac.uk>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109336135.14050.1.camel@mdlinux>
	<Pine.LNX.4.61.0502251543440.31566@netcore.fi>
	<1109657874.bd201ca708ff7@mail.ph.utexas.edu>
	<1109682312.2010.4.camel@mdlinux>
	<20050301152544.GB987@tirian.magd.ox.ac.uk>
Message-ID: <1109696522.28ac5f38a76b9@mail.ph.utexas.edu>

Quoting Dominic Hargreaves <dom at earth.li>:

> It would be nice if the known builders were able to publish to the web

I think this would only take asking Jesse for access, no?

AFAIK, there was always an open door policy on people getting CVS access
to the web site, assuming they showed sufficient "trust" (which any one
who can publish advisory notices obviously has).

-- 
Eric Rostetter



From eric at interplas.com  Tue Mar  1 21:54:58 2005
From: eric at interplas.com (Eric Wood)
Date: Tue, 1 Mar 2005 16:54:58 -0500
Subject: Can we get a zlib update?
Message-ID: <015901c51ea9$4fadbe60$9100000a@M145Primary>

There was a recent security update:
http://fedoralegacy.org/updates/FC1/2005-02-23-FLSA_2005_2043__Updated_zlib_package_fixes_security_issues.html

But, any reason zlib 1.2.2 would break any FC1 or FC2 package?
http://www.gzip.org/zlib/

-eric wood







From ucs_rat at shsu.edu  Tue Mar  1 22:00:08 2005
From: ucs_rat at shsu.edu (Robert A. Thompson)
Date: Tue, 01 Mar 2005 16:00:08 -0600
Subject: Can we get a zlib update?
In-Reply-To: <015901c51ea9$4fadbe60$9100000a@M145Primary>
References: <015901c51ea9$4fadbe60$9100000a@M145Primary>
Message-ID: <4224E5E8.7040304@shsu.edu>

Eric,
    Is there some particular feature your looking for or need? 

--Robert

Eric Wood wrote:

> There was a recent security update:
> http://fedoralegacy.org/updates/FC1/2005-02-23-FLSA_2005_2043__Updated_zlib_package_fixes_security_issues.html 
>
>
> But, any reason zlib 1.2.2 would break any FC1 or FC2 package?
> http://www.gzip.org/zlib/
>
> -eric wood
>
>
>
>
>
> -- 
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list



From eric at interplas.com  Tue Mar  1 22:22:40 2005
From: eric at interplas.com (Eric Wood)
Date: Tue, 1 Mar 2005 17:22:40 -0500
Subject: Can we get a zlib update?
References: <015901c51ea9$4fadbe60$9100000a@M145Primary>
	<4224E5E8.7040304@shsu.edu>
Message-ID: <016701c51ead$2e54ebe0$9100000a@M145Primary>

----- Original Message ----- 
From: "Robert A. Thompson"
> Eric,
>    Is there some particular feature your looking for or need?
> --Robert
>
> Eric Wood wrote:
>
>> There was a recent security update:
>> http://fedoralegacy.org/updates/FC1/2005-02-23-FLSA_2005_2043__Updated_zlib_package_fixes_security_issues.html
>>
>> But, any reason zlib 1.2.2 would break any FC1 or FC2 package?
>> http://www.gzip.org/zlib/
>>
>> -eric wood


Simply because the new ClamAV requires version 1.2.1 and legacy only 
provides us 1.2.0.

I built zlib-1.2.1.2-1.src.rpm from the FC3 repository and it's working well 
on FC1.   So 1.2.2 would be merrier - I don't see any lib compatibility 
problems in the changelog.

-Eric Wood



From jkeating at j2solutions.net  Tue Mar  1 22:26:59 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 01 Mar 2005 14:26:59 -0800
Subject: Can we get a zlib update?
In-Reply-To: <016701c51ead$2e54ebe0$9100000a@M145Primary>
References: <015901c51ea9$4fadbe60$9100000a@M145Primary>
	<4224E5E8.7040304@shsu.edu>
	<016701c51ead$2e54ebe0$9100000a@M145Primary>
Message-ID: <1109716019.904.80.camel@jkeating2.hq.pogolinux.com>

On Tue, 2005-03-01 at 17:22 -0500, Eric Wood wrote:
> Simply because the new ClamAV requires version 1.2.1 and legacy only 
> provides us 1.2.0.

Is Legacy shipping ClamAV?  Is it in any products we support?

> I built zlib-1.2.1.2-1.src.rpm from the FC3 repository and it's
> working well 
> on FC1.   So 1.2.2 would be merrier - I don't see any lib
> compatibility 
> problems in the changelog.

This is not what Legacy is here for.  We don't update just because we
can.  We backport security because it provides maximum stability.  If a
person wants a 3rd party software set that requires newer tools, they
can get the newer tools themselves and deal with the compatibility and
stability issues themselves.

-EWONTFIX

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From ucs_rat at shsu.edu  Tue Mar  1 22:31:14 2005
From: ucs_rat at shsu.edu (Robert A. Thompson)
Date: Tue, 01 Mar 2005 16:31:14 -0600
Subject: Can we get a zlib update?
In-Reply-To: <016701c51ead$2e54ebe0$9100000a@M145Primary>
References: <015901c51ea9$4fadbe60$9100000a@M145Primary>	<4224E5E8.7040304@shsu.edu>
	<016701c51ead$2e54ebe0$9100000a@M145Primary>
Message-ID: <4224ED32.6030406@shsu.edu>


>
> Simply because the new ClamAV requires version 1.2.1 and legacy only 
> provides us 1.2.0.
>
> I built zlib-1.2.1.2-1.src.rpm from the FC3 repository and it's 
> working well on FC1.   So 1.2.2 would be merrier - I don't see any lib 
> compatibility problems in the changelog.
>
> -Eric Wood
>
makes sense.  I went back and re looked at everything after that last 
post, and noticed I mislooked at the bugtraqer thinking it said 1.2.1.  
There wouldn't be much difference between 1.2.1 and 1.2.2 except the 
security fixes.  Makes since with 1.2.0.

--rat



From michal at harddata.com  Wed Mar  2 00:11:02 2005
From: michal at harddata.com (Michal Jaegermann)
Date: Tue, 1 Mar 2005 17:11:02 -0700
Subject: Can we get a zlib update?
In-Reply-To: <016701c51ead$2e54ebe0$9100000a@M145Primary>;
	from eric@interplas.com on Tue, Mar 01, 2005 at 05:22:40PM -0500
References: <015901c51ea9$4fadbe60$9100000a@M145Primary>
	<4224E5E8.7040304@shsu.edu>
	<016701c51ead$2e54ebe0$9100000a@M145Primary>
Message-ID: <20050301171102.B23979@mail.harddata.com>

On Tue, Mar 01, 2005 at 05:22:40PM -0500, Eric Wood wrote:
> 
> Simply because the new ClamAV requires version 1.2.1 and legacy only 
> provides us 1.2.0.

Which ClamAV requires 1.2.1?  AFAIK 0.83 is the latest release
and it recompiles just fine with zlib-1.1.4.

    Michal



From dom at earth.li  Wed Mar  2 00:56:43 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Wed, 2 Mar 2005 00:56:43 +0000
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <1109696522.28ac5f38a76b9@mail.ph.utexas.edu>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109336135.14050.1.camel@mdlinux>
	<Pine.LNX.4.61.0502251543440.31566@netcore.fi>
	<1109657874.bd201ca708ff7@mail.ph.utexas.edu>
	<1109682312.2010.4.camel@mdlinux>
	<20050301152544.GB987@tirian.magd.ox.ac.uk>
	<1109696522.28ac5f38a76b9@mail.ph.utexas.edu>
Message-ID: <20050302005643.GE987@tirian.magd.ox.ac.uk>

On Tue, Mar 01, 2005 at 11:02:02AM -0600, Eric Rostetter wrote:

> AFAIK, there was always an open door policy on people getting CVS access
> to the web site, assuming they showed sufficient "trust" (which any one
> who can publish advisory notices obviously has).

Okay. I think perhaps there were technical problems at the time that I
asked before. Count me in as interested, Jesse.

Cheers,

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



From eric at interplas.com  Wed Mar  2 02:25:21 2005
From: eric at interplas.com (Eric Wood)
Date: Tue, 1 Mar 2005 21:25:21 -0500
Subject: Can we get a zlib update?
References: <015901c51ea9$4fadbe60$9100000a@M145Primary><4224E5E8.7040304@shsu.edu><016701c51ead$2e54ebe0$9100000a@M145Primary>
	<20050301171102.B23979@mail.harddata.com>
Message-ID: <001f01c51ecf$1588d640$6601a8c0@vaio>


----- Original Message ----- 
From: "Michal Jaegermann"
> On Tue, Mar 01, 2005 at 05:22:40PM -0500, Eric Wood wrote:
>>
>> Simply because the new ClamAV requires version 1.2.1 and legacy only
>> provides us 1.2.0.
>
> Which ClamAV requires 1.2.1?  AFAIK 0.83 is the latest release
> and it recompiles just fine with zlib-1.1.4.

Well, that's the achilles heel with rpm.  There's tons of rpms out there 
that will work fine and compile fine with older dependant package but theres 
a superficial requirement that a newer package is need.

-eric wood 



From eric at interplas.com  Wed Mar  2 02:32:03 2005
From: eric at interplas.com (Eric Wood)
Date: Tue, 1 Mar 2005 21:32:03 -0500
Subject: Can we get a zlib update?
References: <015901c51ea9$4fadbe60$9100000a@M145Primary><4224E5E8.7040304@shsu.edu><016701c51ead$2e54ebe0$9100000a@M145Primary>
	<1109716019.904.80.camel@jkeating2.hq.pogolinux.com>
Message-ID: <002201c51ed0$051a2ec0$6601a8c0@vaio>


----- Original Message ----- 
From: "Jesse Keating"
> This is not what Legacy is here for.  We don't update just because we
> can.  We backport security because it provides maximum stability.  If a
> person wants a 3rd party software set that requires newer tools, they
> can get the newer tools themselves and deal with the compatibility and
> stability issues themselves.
>
> -EWONTFIX

Ummmmmmmmmmmmmmm.........

 October 3rd, 2004
" Version 1.2.2 eliminates a potential security vulnerability in zlib 1.2.1, 
so all users of 1.2.1 should upgrade immediately."

I'm no expert to firmly disagree with you. With such a small changelog, why 
not go for 1.2.2 and be done with it in this special case?

I like their slogan:
"A Massively Spiffy Yet Delicately Unobtrusive Compression Library"

-Eric Wood 



From marcdeslauriers at videotron.ca  Wed Mar  2 03:22:28 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Tue, 01 Mar 2005 22:22:28 -0500
Subject: Can we get a zlib update?
In-Reply-To: <016701c51ead$2e54ebe0$9100000a@M145Primary>
References: <015901c51ea9$4fadbe60$9100000a@M145Primary>
	<4224E5E8.7040304@shsu.edu>
	<016701c51ead$2e54ebe0$9100000a@M145Primary>
Message-ID: <1109733748.11843.4.camel@mdlinux>

On Tue, 2005-03-01 at 17:22 -0500, Eric Wood wrote:

> Simply because the new ClamAV requires version 1.2.1 and legacy only 
> provides us 1.2.0.

ClamAV doesn't require 1.2.1. It just checks to make sure you're not
using an older version with known security issues by blindly looking at
the version number. The zlib rpm present in FC1, FC2 and FC3 has been
patched with backported security fixes and clamav will work just fine
with them by using the "--disable-zlib-vcheck" configure option.

Marc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050301/12247bda/attachment.sig>

From mattdm at mattdm.org  Wed Mar  2 03:49:53 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 1 Mar 2005 22:49:53 -0500
Subject: Can we get a zlib update?
In-Reply-To: <001f01c51ecf$1588d640$6601a8c0@vaio>
References: <20050301171102.B23979@mail.harddata.com>
	<001f01c51ecf$1588d640$6601a8c0@vaio>
Message-ID: <20050302034953.GA9754@jadzia.bu.edu>

On Tue, Mar 01, 2005 at 09:25:21PM -0500, Eric Wood wrote:
> Well, that's the achilles heel with rpm.  There's tons of rpms out there 
> that will work fine and compile fine with older dependant package but 
> theres a superficial requirement that a newer package is need.

Huh?

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From jkeating at j2solutions.net  Wed Mar  2 07:46:09 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 01 Mar 2005 23:46:09 -0800
Subject: Can we get a zlib update?
In-Reply-To: <002201c51ed0$051a2ec0$6601a8c0@vaio>
References: <015901c51ea9$4fadbe60$9100000a@M145Primary>
	<4224E5E8.7040304@shsu.edu><016701c51ead$2e54ebe0$9100000a@M145Primary>
	<1109716019.904.80.camel@jkeating2.hq.pogolinux.com>
	<002201c51ed0$051a2ec0$6601a8c0@vaio>
Message-ID: <1109749569.13489.24.camel@localhost.localdomain>

On Tue, 2005-03-01 at 21:32 -0500, Eric Wood wrote:
> Ummmmmmmmmmmmmmm.........
> 
>  October 3rd, 2004
> " Version 1.2.2 eliminates a potential security vulnerability in zlib
> 1.2.1, 
> so all users of 1.2.1 should upgrade immediately."
> 
> I'm no expert to firmly disagree with you. With such a small
> changelog, why 
> not go for 1.2.2 and be done with it in this special case?

I had not reviewed the changelog.  If zlib did the work for us, and the
only difference between our version and their version is the security
patches, then your software would work with our version no?

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050301/a12f6e9c/attachment.sig>

From eric at interplas.com  Wed Mar  2 13:50:14 2005
From: eric at interplas.com (Eric Wood)
Date: Wed, 2 Mar 2005 08:50:14 -0500
Subject: Can we get a zlib update?
References: <015901c51ea9$4fadbe60$9100000a@M145Primary><4224E5E8.7040304@shsu.edu><016701c51ead$2e54ebe0$9100000a@M145Primary><1109716019.904.80.camel@jkeating2.hq.pogolinux.com><002201c51ed0$051a2ec0$6601a8c0@vaio>
	<1109749569.13489.24.camel@localhost.localdomain>
Message-ID: <004a01c51f2e$c2f48a90$9100000a@M145Primary>

From: "Jesse Keating"
> I had not reviewed the changelog.  If zlib did the work for us, and the
> only difference between our version and their version is the security
> patches, then your software would work with our version no?


I just think the version is artificially being kept down cause I don't see 
any substatial diff in the code except for tab indents.

I'm fine, I just argue the point that the buck stops at zlib and it can 
easily be kept up across all FC releases.

-eric wood 



From eric.rostetter at physics.utexas.edu  Tue Mar  1 06:13:42 2005
From: eric.rostetter at physics.utexas.edu (Eric Rostetter)
Date: Tue,  1 Mar 2005 00:13:42 -0600
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
Message-ID: <1109657622.4e8fec4f11962@mail.ph.utexas.edu>

Quoting Pekka Savola <pekkas at netcore.fi>:

> Hi,
> 
> It appears the advisories haven't been updated on:
> 
> http://www.fedoralegacy.org/updates/

They should be asap, as I'm back from vacation now.

> .. hopefully these aren't updated manually?!?!? Or did a script break?

I've asked about getting a lot of automation done, even volunteered to
do some of it, but so far have no been given permission to do anything.
Jesse has said he planned to do some, but has not been able to get around
to it.  So, as of now, it is more-or-less by hand.

Actual setup isn't so hard:

* I save the message from my e-mail client to my disk in a CVS checkout of the
web site
* I run a php script (in CVS) on it, to create the HTML output
* I copy the html output to the proper directories for the relavent releases
* I do a CVS add/commit on the new files
* I update the web site from CVS.

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin
 
Why get even? Get odd!



From dom at earth.li  Wed Mar  2 00:17:02 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Wed, 2 Mar 2005 00:17:02 +0000
Subject: [FLSA-2005:2314] Updated XFree86 packages fix security flaws
Message-ID: <20050302001655.GA30543@home.thedom.org>

-----------------------------------------------------------------------
               Fedora Legacy Update Advisory

Synopsis:          Updated XFree86 resolves security vulnerabilities
Advisory ID:       FLSA:2314
Issue date:        2005-03-01
Product:           Red Hat Linux
Product:           Fedora Core
Keywords:          Security
Cross references:  https://bugzilla.fedora.us/show_bug.cgi?id=2314
CVE Names:         CAN-2004-0083, CAN-2004-0084, CAN-2004-0106,
                   CAN-2004-0419, CAN-2004-0687, CAN-2004-0688,
                   CAN-2004-0692, CAN-2004-0914
-----------------------------------------------------------------------


-----------------------------------------------------------------------
1. Topic:

Updated XFree86 packages that fix multiple security flaws are now
available.

XFree86 is an open source implementation of the X Window System. It
provides the basic low level functionality which full fledged graphical
user interfaces (GUIs) such as GNOME and KDE are designed upon.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386

3. Problem description:

Note that some of these issues have already been fixed in Redhat 9 and
Fedora Core 1. Please refer to previous advisories for details.

iDefense discovered two buffer overflows in the parsing of the 'font.alias'
file. A local attacker could exploit this vulnerability by creating a
carefully-crafted file and gaining root privileges.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the names CAN-2004-0083 and CAN-2004-0084 to these issues.

Additionally David Dawes discovered additional flaws in reading font files.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0106 to these issues.

Steve Rumble discovered that xdm in XFree86 opens a chooserFd TCP socket
even when DisplayManager.requestPort is 0, which could allow remote
attackers to connect to the port, in violation of the intended
restrictions. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2004-0419 to these issues.

During a source code audit, Chris Evans discovered several stack overflow
flaws and an integer overflow flaw in the X.Org libXpm library used to
decode XPM (X PixMap) images. An attacker could create a carefully crafted
XPM file which would cause an application to crash or potentially execute
arbitrary code if opened by a victim. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the names CAN-2004-0687,
CAN-2004-0688, CAN-2004-0692 and CAN-2004-0914 to these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which are
not installed but included in the list will not be updated.  Note that you
can also use wildcards (*.rpm) if your current directory *only* contains
the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system.  This assumes that you have yum or
apt-get configured for obtaining Fedora Legacy content. Please visit
http://www.fedoralegacy.org/docs/ for directions on how to configure yum
and apt-get.

5. Bug IDs fixed:

http://bugzilla.fedora.us - 1289 -
XFree86 Font Information File Buffer Overflow
http://bugzilla.fedora.us - 1831 -
CAN-2004-0419 - XDM in XFree86 socket open vulnerability
http://bugzilla.fedora.us - 2075 -
CAN-2004-0687,0688 libXpm stack and integer overflows
http://bugzilla.fedora.us - 2314 -
XFree86 libXpm Multiple Vulnerabilities CAN-2004-0914

6. RPMs required:

Red Hat Linux 7.3:

SRPM:

http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/XFree86-4.2.1-16.73.30.legacy.src.rpm

i386:

http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-100dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-75dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-base-fonts-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-cyrillic-fonts-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-devel-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-doc-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-font-utils-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-libs-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-tools-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-truetype-fonts-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-twm-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-xdm-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-xf86cfg-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-xfs-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-Xnest-4.2.1-16.73.30.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/XFree86-Xvfb-4.2.1-16.73.30.legacy.i386.rpm

Red Hat Linux 9:

SRPM:

http://download.fedoralegacy.org/redhat/9/updates/SRPMS/XFree86-4.3.0-2.90.60.legacy.src.rpm

i386: 

http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-100dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-75dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-base-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-cyrillic-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-devel-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-doc-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-font-utils-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-14-100dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-14-75dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-libs-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-libs-data-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-Mesa-libGL-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-Mesa-libGLU-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-sdk-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-syriac-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-tools-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-truetype-fonts-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-twm-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-xauth-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-xdm-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-xfs-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-Xnest-4.3.0-2.90.60.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/XFree86-Xvfb-4.3.0-2.90.60.legacy.i386.rpm

Fedora Core 1:

SRPM:

http://download.fedoralegacy.org/fedora/1/updates/SRPMS/XFree86-4.3.0-59.legacy.src.rpm

i386:

http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-100dpi-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-75dpi-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-base-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-cyrillic-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-devel-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-doc-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-font-utils-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-14-100dpi-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-14-75dpi-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-libs-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-libs-data-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-Mesa-libGL-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-Mesa-libGLU-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-sdk-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-syriac-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-tools-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-truetype-fonts-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-twm-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-xauth-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-xdm-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-xfs-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-Xnest-4.3.0-59.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/XFree86-Xvfb-4.3.0-59.legacy.i386.rpm

7. Verification:

SHA1 sum                                 Package Name
---------------------------------------------------------------------------

2c38279e15e8510c85400780da3ee41b57b81ffa  redhat/7.3/updates/SRPMS/XFree86-4.2.1-16.73.30.legacy.src.rpm
dc1ac97e2f0077915a4f3d56dd32d14c0429faa6  redhat/7.3/updates/i386/XFree86-100dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
df4fac2134c20410c7df415c7ced94ccc08cf36b  redhat/7.3/updates/i386/XFree86-4.2.1-16.73.30.legacy.i386.rpm
c6e3b08145f73a85be39e301ac2df2015c37a036  redhat/7.3/updates/i386/XFree86-75dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
f0bec0c03de0c977be1d5b4e34b09dd348f34c14  redhat/7.3/updates/i386/XFree86-base-fonts-4.2.1-16.73.30.legacy.i386.rpm
794fb0cf67a1b1ef84d247fc90a0138e70d85c4f  redhat/7.3/updates/i386/XFree86-cyrillic-fonts-4.2.1-16.73.30.legacy.i386.rpm
ac82944f56aba63f6d64068ddc5a6bd4e55fae94  redhat/7.3/updates/i386/XFree86-devel-4.2.1-16.73.30.legacy.i386.rpm
a3b4043417d7069f095471daf2f72153f9a31ea4  redhat/7.3/updates/i386/XFree86-doc-4.2.1-16.73.30.legacy.i386.rpm
1c28ae585d90ad3bd73e4cb6eff32035d54dbec9  redhat/7.3/updates/i386/XFree86-font-utils-4.2.1-16.73.30.legacy.i386.rpm
ab51270528cb8970f19d21c35de093840c9eacc4  redhat/7.3/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
d06490ffd58c498b6c3392a02e2f1f52368c1699  redhat/7.3/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
81c5bb28ee0493c53dbee38f8312f73279481e49  redhat/7.3/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
8a9d4c1ea6f3dddd0787009015e3bf66d194beb3  redhat/7.3/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
b65333c64e90524b437c1c5ffe0a1eded2deab9d  redhat/7.3/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
5f0cbdd132954a813d2e4b187d37f9e4e4613a32  redhat/7.3/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.2.1-16.73.30.legacy.i386.rpm
d4ee4c7adf9e6a6f533a09cabfcfe9b6f11f8628  redhat/7.3/updates/i386/XFree86-libs-4.2.1-16.73.30.legacy.i386.rpm
af869d4a76601d739a90c05cac61f2112ad753e5  redhat/7.3/updates/i386/XFree86-tools-4.2.1-16.73.30.legacy.i386.rpm
629b596d824fb31558eef1eef05dd6b63ce2a15b  redhat/7.3/updates/i386/XFree86-truetype-fonts-4.2.1-16.73.30.legacy.i386.rpm
fe63ec2dd3f402ee2e9f05417969c58f276e3d8a  redhat/7.3/updates/i386/XFree86-twm-4.2.1-16.73.30.legacy.i386.rpm
95ef4f17e9e282b48979c3b491447738679b5b3e  redhat/7.3/updates/i386/XFree86-xdm-4.2.1-16.73.30.legacy.i386.rpm
a52fa2bebe3f9aa2fa37409ddf4aa57b01abd435  redhat/7.3/updates/i386/XFree86-xf86cfg-4.2.1-16.73.30.legacy.i386.rpm
7bc973b06812281b3c102a9721cd824747b8b8a8  redhat/7.3/updates/i386/XFree86-xfs-4.2.1-16.73.30.legacy.i386.rpm
18d0442ed2d6a31eaf870c6ab7d727b2f6696351  redhat/7.3/updates/i386/XFree86-Xnest-4.2.1-16.73.30.legacy.i386.rpm
77215ad43ad1b77f6f1527af7d642ad6c5dc40ce  redhat/7.3/updates/i386/XFree86-Xvfb-4.2.1-16.73.30.legacy.i386.rpm

ff7072e0b55decdd13453ce3532588c32597de61  redhat/9/updates/SRPMS/XFree86-4.3.0-2.90.60.legacy.src.rpm
ed4d03ede26a89422825ad18ce6e14a7831927eb  redhat/9/updates/i386/XFree86-100dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
f4f99ff79a7d1eeca726cb61a536c5884bbdadac  redhat/9/updates/i386/XFree86-4.3.0-2.90.60.legacy.i386.rpm
dc9b89287ea04b5acafac200f8c8483cbdb74cce  redhat/9/updates/i386/XFree86-75dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
f8210a9eb148259a1d402dfdd7f58075dfd022a6  redhat/9/updates/i386/XFree86-base-fonts-4.3.0-2.90.60.legacy.i386.rpm
caad110605ae0aaa91f93cd79d9bea5d3ae73431  redhat/9/updates/i386/XFree86-cyrillic-fonts-4.3.0-2.90.60.legacy.i386.rpm
6502feec18a9e2f325551f90c8a2a3e260f1915a  redhat/9/updates/i386/XFree86-devel-4.3.0-2.90.60.legacy.i386.rpm
b9c797cc7202aa43c824474713b1fee447039b1f  redhat/9/updates/i386/XFree86-doc-4.3.0-2.90.60.legacy.i386.rpm
b4efa8b07bfc3c5a4441b89acd02266c1618d138  redhat/9/updates/i386/XFree86-font-utils-4.3.0-2.90.60.legacy.i386.rpm
db7c826e976913123caae9bc20303655c758a047  redhat/9/updates/i386/XFree86-ISO8859-14-100dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
23f5c9db2e532aabdc6f47f629458d69da92d303  redhat/9/updates/i386/XFree86-ISO8859-14-75dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
14d720d254b1f26633ebee78b76273f38b8ee46b  redhat/9/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
dffce9814a821f9d4b4703bfb98e5aa04ef221bc  redhat/9/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
70b0606839ef7c14eff38851e2fab6a7896992dc  redhat/9/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
01fa202f3915e2d6a123f150e367feff82d42d1f  redhat/9/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
e640fe73f9f6769d38d59fa01bdce78e2ef71bdd  redhat/9/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
f253cb5b83610f7168762978335beef8b45a3f59  redhat/9/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.3.0-2.90.60.legacy.i386.rpm
694f32b8c7a4be52008de92f41347e3af51ee9e7  redhat/9/updates/i386/XFree86-libs-4.3.0-2.90.60.legacy.i386.rpm
95f6355f42e885ff21d87788975c28adbc2b75e9  redhat/9/updates/i386/XFree86-libs-data-4.3.0-2.90.60.legacy.i386.rpm
1b88a4c736fd2aa5409d4ee23ad626aa95c9c816  redhat/9/updates/i386/XFree86-Mesa-libGL-4.3.0-2.90.60.legacy.i386.rpm
18d4247c77182cd7cd569b949a5483a968043723  redhat/9/updates/i386/XFree86-Mesa-libGLU-4.3.0-2.90.60.legacy.i386.rpm
3335a0096695baa109f35c64c9ead7a3072fc28c  redhat/9/updates/i386/XFree86-sdk-4.3.0-2.90.60.legacy.i386.rpm
d069175adc265f31b0ff48ea78cdd59203146ab9  redhat/9/updates/i386/XFree86-syriac-fonts-4.3.0-2.90.60.legacy.i386.rpm
0a6ae9b0f3b640ce528ef153e33536c6ba4b9d2f  redhat/9/updates/i386/XFree86-tools-4.3.0-2.90.60.legacy.i386.rpm
b78bfd843f2c6a9cb31957ad6ab2dbf6c4d25632  redhat/9/updates/i386/XFree86-truetype-fonts-4.3.0-2.90.60.legacy.i386.rpm
f72ff04509739828871044b8e246bbb98cb26500  redhat/9/updates/i386/XFree86-twm-4.3.0-2.90.60.legacy.i386.rpm
b1043925fffe7bd714d025372242778a6f03e7ed  redhat/9/updates/i386/XFree86-xauth-4.3.0-2.90.60.legacy.i386.rpm
3ed9fb9f0de675fe92b671e1d0432bda531daa41  redhat/9/updates/i386/XFree86-xdm-4.3.0-2.90.60.legacy.i386.rpm
6aff7d5ff0e5f5e22c471c9113bffa25fd6b5478  redhat/9/updates/i386/XFree86-xfs-4.3.0-2.90.60.legacy.i386.rpm
42f8c36e72ae33cdc98b4a2e78771fa3f121351c  redhat/9/updates/i386/XFree86-Xnest-4.3.0-2.90.60.legacy.i386.rpm
67c6176f5d673238b58ae3f79d446ab0da258607  redhat/9/updates/i386/XFree86-Xvfb-4.3.0-2.90.60.legacy.i386.rpm

f506c7f1286ed9d252840d56e5bfd3e10323f260  fedora/1/updates/SRPMS/XFree86-4.3.0-59.legacy.src.rpm
41dc2c5e92530ee276092e7a6ef0711242a6d802  fedora/1/updates/i386/XFree86-100dpi-fonts-4.3.0-59.legacy.i386.rpm
e0e6865d27c7ef62fff9cae59adc0d241901435f  fedora/1/updates/i386/XFree86-4.3.0-59.legacy.i386.rpm
21e69dd9ba1e1561b2d13be7d992975dca4326e0  fedora/1/updates/i386/XFree86-75dpi-fonts-4.3.0-59.legacy.i386.rpm
19089ae7b10a16531a050f26e924ff7afd6cab84  fedora/1/updates/i386/XFree86-base-fonts-4.3.0-59.legacy.i386.rpm
5ef293ae847c995d39f41c57821739e3cc3bb74b  fedora/1/updates/i386/XFree86-cyrillic-fonts-4.3.0-59.legacy.i386.rpm
97bd48f5887c5b8c2a5a6739e0a931af4f99e6af  fedora/1/updates/i386/XFree86-devel-4.3.0-59.legacy.i386.rpm
8d254544eed188d5c2fbc5fa303dceda6886d3cb  fedora/1/updates/i386/XFree86-doc-4.3.0-59.legacy.i386.rpm
2c1974d8dc69f98957358724c72d36c2d74eb0b7  fedora/1/updates/i386/XFree86-font-utils-4.3.0-59.legacy.i386.rpm
b43e195b60add11ebed29c840655986aefae4bdb  fedora/1/updates/i386/XFree86-ISO8859-14-100dpi-fonts-4.3.0-59.legacy.i386.rpm
93d3b1c7f1ccb4774b2db353dd031767c3389c58  fedora/1/updates/i386/XFree86-ISO8859-14-75dpi-fonts-4.3.0-59.legacy.i386.rpm
8a3b08dfea526be7655f7f3f2bfe0935167ca326  fedora/1/updates/i386/XFree86-ISO8859-15-100dpi-fonts-4.3.0-59.legacy.i386.rpm
50c0018cd62b5a09c0becc2c7fb125cb11aaed86  fedora/1/updates/i386/XFree86-ISO8859-15-75dpi-fonts-4.3.0-59.legacy.i386.rpm
50691dd23bd82ac66f894561d52ae4f30d9e6be4  fedora/1/updates/i386/XFree86-ISO8859-2-100dpi-fonts-4.3.0-59.legacy.i386.rpm
f1e8391db079f6479c47b31f02d283eb64e1b372  fedora/1/updates/i386/XFree86-ISO8859-2-75dpi-fonts-4.3.0-59.legacy.i386.rpm
b4f1a8aaab2168d801239de9ec4631b5f5f952c5  fedora/1/updates/i386/XFree86-ISO8859-9-100dpi-fonts-4.3.0-59.legacy.i386.rpm
c90c9f1086ade943c819159e1e9c4da609ee20bc  fedora/1/updates/i386/XFree86-ISO8859-9-75dpi-fonts-4.3.0-59.legacy.i386.rpm
6969c834e092c7f17d736ae4ab7d13020446b088  fedora/1/updates/i386/XFree86-libs-4.3.0-59.legacy.i386.rpm
40401fae64837023cf5ad321914ed35b0569e1fb  fedora/1/updates/i386/XFree86-libs-data-4.3.0-59.legacy.i386.rpm
c77ae20f5e95c2013ab5b79c747c50a1aeb2ff9f  fedora/1/updates/i386/XFree86-Mesa-libGL-4.3.0-59.legacy.i386.rpm
6acb61f2ccb56125b8bb6b0bbb33aca393b41bfa  fedora/1/updates/i386/XFree86-Mesa-libGLU-4.3.0-59.legacy.i386.rpm
b5ed6846d3c5267890f75bb2967719a77251077b  fedora/1/updates/i386/XFree86-sdk-4.3.0-59.legacy.i386.rpm
a2593f5ad70cf863bc1a50065d4cf959c396b290  fedora/1/updates/i386/XFree86-syriac-fonts-4.3.0-59.legacy.i386.rpm
77ef806dd3a962e13300cfaafc5761cd453e42fd  fedora/1/updates/i386/XFree86-tools-4.3.0-59.legacy.i386.rpm
004636b99489d8d9d0da9a89d112fbca85b51e7b  fedora/1/updates/i386/XFree86-truetype-fonts-4.3.0-59.legacy.i386.rpm
61442fea052c2c9bb4cd52b836f83be39dd51645  fedora/1/updates/i386/XFree86-twm-4.3.0-59.legacy.i386.rpm
adee8168ca51a34a7f33a1af4e51ad2409a244fb  fedora/1/updates/i386/XFree86-xauth-4.3.0-59.legacy.i386.rpm
60bc51efdcfa0e4062404ba4e7083e9927f16e33  fedora/1/updates/i386/XFree86-xdm-4.3.0-59.legacy.i386.rpm
ffbeaab8ac66e40cac0eeac685a8567bda43517b  fedora/1/updates/i386/XFree86-xfs-4.3.0-59.legacy.i386.rpm
23b0cdbf749a8eadb3dce701ab4bfd57e65777fe  fedora/1/updates/i386/XFree86-Xnest-4.3.0-59.legacy.i386.rpm
7ee79dd5f9a1efd0d2881c0d426951b9c9eac44f  fedora/1/updates/i386/XFree86-Xvfb-4.3.0-59.legacy.i386.rpm

These packages are GPG signed by Fedora Legacy for security.  Our key is
available from http://www.fedoralegacy.org/about/security.php

You can verify each package with the following command:

    rpm --checksig -v <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the sha1sum with the following command:

    sha1sum <filename>

8. References:

https://rhn.redhat.com/errata/RHSA-2004-060.html
https://rhn.redhat.com/errata/RHSA-2004-478.html
https://rhn.redhat.com/errata/RHSA-2004-610.html

9. Contact:

The Fedora Legacy security contact is <secnotice at fedoralegacy.org>. More
project details at http://www.fedoralegacy.org

---------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050302/64768fde/attachment.sig>

From marcdeslauriers at videotron.ca  Wed Mar  2 13:04:07 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Wed, 02 Mar 2005 08:04:07 -0500
Subject: [FLSA-2005:2127] Updated CUPS packages fix security vulnerabilities
Message-ID: <4225B9C7.7020604@videotron.ca>

-----------------------------------------------------------------------
                Fedora Legacy Update Advisory

Synopsis:          Updated CUPS packages fix security vulnerabilities
Advisory ID:       FLSA:2127
Issue date:        2005-03-02
Product:           Red Hat Linux, Fedora Core
Keywords:          Bugfix
Cross references:  https://bugzilla.fedora.us/show_bug.cgi?id=2127
CVE Names:         CAN-2004-0888 CAN-2004-0923 CAN-2004-1125
                    CAN-2004-1267 CAN-2004-1268 CAN-2004-1269
                    CAN-2004-1270 CAN-2005-0064
-----------------------------------------------------------------------


-----------------------------------------------------------------------
1. Topic:

Updated CUPS packages that fix several security issues are now
available.

The Common UNIX Printing System provides a portable printing layer for
UNIX(R) operating systems.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386

3. Problem description:

During a source code audit, Chris Evans discovered a number of integer
overflow bugs that affect xpdf. CUPS contains a copy of the xpdf code
used for parsing PDF files and is therefore affected by these bugs. An
attacker who has the ability to send a malicious PDF file to a printer
could cause CUPS to crash or possibly execute arbitrary code. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-0888 to this issue.

When set up to print to a shared printer via Samba, CUPS would
authenticate with that shared printer using a username and password. By
default, the username and password used to connect to the Samba share is
written into the error log file. A local user who is able to read the
error log file could collect these usernames and passwords. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-0923 to this issue.

A buffer overflow was found in the CUPS pdftops filter, which uses code
from the Xpdf package. An attacker who has the ability to send a
malicious PDF file to a printer could possibly execute arbitrary code as
the "lp" user. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2004-1125 to this issue.

A buffer overflow was found in the ParseCommand function in the hpgltops
program. An attacker who has the ability to send a malicious HPGL file
to a printer could possibly execute arbitrary code as the "lp" user. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-1267 to this issue.

The lppasswd utility ignores write errors when modifying the CUPS passwd
file. A local user who is able to fill the associated file system could
corrupt the CUPS password file or prevent future uses of lppasswd. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the names CAN-2004-1268 and CAN-2004-1269 to these issues.

The lppasswd utility does not verify that the passwd.new file is
different from STDERR, which could allow local users to control output
to passwd.new via certain user input that triggers an error message. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-1270 to this issue.

A buffer overflow flaw was found in the Decrypt::makeFileKey2 function
of Xpdf which also affects the CUPS pdftops filter due to a shared
codebase. An attacker who has the ability to send a malicious PDF file
to a printer could possibly execute arbitrary code as the "lp" user. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2005-0064 to this issue.

All users of cups should upgrade to these updated packages, which
resolve these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

http://bugzilla.fedora.us - 2127 - multiple cups vulns

6. RPMs required:

Red Hat Linux 7.3:

SRPM:
http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/cups-1.1.14-15.4.4.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/7.3/updates/i386/cups-1.1.14-15.4.4.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/cups-devel-1.1.14-15.4.4.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/cups-libs-1.1.14-15.4.4.legacy.i386.rpm

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/cups-1.1.17-13.3.0.13.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/cups-1.1.17-13.3.0.13.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/cups-devel-1.1.17-13.3.0.13.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/cups-libs-1.1.17-13.3.0.13.legacy.i386.rpm

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/cups-1.1.19-13.8.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/cups-1.1.19-13.8.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/cups-devel-1.1.19-13.8.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/cups-libs-1.1.19-13.8.legacy.i386.rpm

7. Verification:

SHA1 sum                                 Package Name
---------------------------------------------------------------------------

0db34c2e38a4041f73d2a78a9b2915f75a66c24a 
redhat/7.3/updates/i386/cups-1.1.14-15.4.4.legacy.i386.rpm
daae4200a9bbf7e7b9fafa28bb46e07028f9e8c5 
redhat/7.3/updates/i386/cups-devel-1.1.14-15.4.4.legacy.i386.rpm
7274fee7375ae5daf0824091ae394544a45fbe1a 
redhat/7.3/updates/i386/cups-libs-1.1.14-15.4.4.legacy.i386.rpm
c069522837c744b29cb67ea52e00023110400e70 
redhat/7.3/updates/SRPMS/cups-1.1.14-15.4.4.legacy.src.rpm
c6fdf900397f732b510fbfa21a5fa977e984c2cb 
redhat/9/updates/i386/cups-1.1.17-13.3.0.13.legacy.i386.rpm
a18781d8f285db684790d32b9a8eca4ca4504124 
redhat/9/updates/i386/cups-devel-1.1.17-13.3.0.13.legacy.i386.rpm
01741a487d1a9ffdede42fbe0e80f1bfa09250f7 
redhat/9/updates/i386/cups-libs-1.1.17-13.3.0.13.legacy.i386.rpm
2d0734d15d4d72ebd72a03c62886f87c4f8fc0fb 
redhat/9/updates/SRPMS/cups-1.1.17-13.3.0.13.legacy.src.rpm
9637c0555edd133c1fb8ef7c7818c3e794408e04 
fedora/1/updates/i386/cups-1.1.19-13.8.legacy.i386.rpm
bc4b60d13ac3cae0a047149b9f8350a4ca8bb427 
fedora/1/updates/i386/cups-devel-1.1.19-13.8.legacy.i386.rpm
3a1fea385f2fc5302e9529ed64cb36c17d64ed3f 
fedora/1/updates/i386/cups-libs-1.1.19-13.8.legacy.i386.rpm
132ca29e094556c2f575f811cad907efd3a6cdad 
fedora/1/updates/SRPMS/cups-1.1.19-13.8.legacy.src.rpm

These packages are GPG signed by Fedora Legacy for security.  Our key is
available from http://www.fedoralegacy.org/about/security.php

You can verify each package with the following command:

     rpm --checksig -v <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the sha1sum with the following command:

     sha1sum <filename>

8. References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0888
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0923
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1125
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1267
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1268
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1269
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1270
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0064

9. Contact:

The Fedora Legacy security contact is <secnotice at fedoralegacy.org>. More
project details at http://www.fedoralegacy.org

---------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050302/fc1df7dc/attachment.sig>

From cra at WPI.EDU  Wed Mar  2 15:43:15 2005
From: cra at WPI.EDU (Chuck R. Anderson)
Date: Wed, 2 Mar 2005 10:43:15 -0500
Subject: Which PC to try FC2 on first?
In-Reply-To: <pan.2005.02.24.21.19.50.507647@adelphia.net>
References: <pan.2005.02.24.21.19.50.507647@adelphia.net>
Message-ID: <20050302154315.GM28055@angus.ind.WPI.EDU>

On Thu, Feb 24, 2005 at 04:19:52PM -0500, beartooth wrote:
> So which machine would you try FC2 on first, and why? Or is a clean
> install the only way to get from FC1 to FC2 -- still? (I recall people
> here saying so when FC2 was newly out.) And in either case, how do I make
> sure when I get to the map machine that FC2 doesn't touch the XP part?

Fedora and Red Hat have *always* been upgradeable.  Why not try FC3 on 
it?  No sense in using FC2, which is going to be obsolete soon.



From maillist at jasonlim.com  Wed Mar  2 16:15:17 2005
From: maillist at jasonlim.com (Jason Lim)
Date: Thu, 3 Mar 2005 00:15:17 +0800
Subject: Fedora Legacy advistory list is lacking
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109657622.4e8fec4f11962@mail.ph.utexas.edu>
Message-ID: <011e01c51f43$0b5de560$0900a8c0@SYSTEM9>


>
> I've asked about getting a lot of automation done, even volunteered to
> do some of it, but so far have no been given permission to do anything.
> Jesse has said he planned to do some, but has not been able to get
around
> to it.  So, as of now, it is more-or-less by hand.
>
> Actual setup isn't so hard:
>
> * I save the message from my e-mail client to my disk in a CVS checkout
of the
> web site
> * I run a php script (in CVS) on it, to create the HTML output
> * I copy the html output to the proper directories for the relavent
releases
> * I do a CVS add/commit on the new files
> * I update the web site from CVS.
>

I can help out with some automation/scripting as well, if only i knew
exactly what needed to be done.

By the way, I was wondering if FL needed any donated server(s) for
building or testing packages? Or are we simply looking for download
mirrors?



From sheltren at cs.ucsb.edu  Wed Mar  2 16:18:06 2005
From: sheltren at cs.ucsb.edu (Jeff Sheltren)
Date: Wed, 02 Mar 2005 08:18:06 -0800
Subject: Can we get a zlib update?
In-Reply-To: <1109749569.13489.24.camel@localhost.localdomain>
Message-ID: <BE4B273E.1D6A9%sheltren@cs.ucsb.edu>

On 3/1/05 11:46 PM, "Jesse Keating" <jkeating at j2solutions.net> wrote:
> I had not reviewed the changelog.  If zlib did the work for us, and the
> only difference between our version and their version is the security
> patches, then your software would work with our version no?

Yes, if it is ClamAV they are talking about, it works fine with the older
version of glib - it just spits out a warning letting you know that it's not
their fault if their software breaks using the older glib...

-Jeff




From jkeating at j2solutions.net  Wed Mar  2 16:40:09 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 02 Mar 2005 08:40:09 -0800
Subject: Fedora Legacy advistory list is lacking
In-Reply-To: <011e01c51f43$0b5de560$0900a8c0@SYSTEM9>
References: <Pine.LNX.4.61.0502251102380.25569@netcore.fi>
	<1109657622.4e8fec4f11962@mail.ph.utexas.edu>
	<011e01c51f43$0b5de560$0900a8c0@SYSTEM9>
Message-ID: <1109781609.904.108.camel@jkeating2.hq.pogolinux.com>

On Thu, 2005-03-03 at 00:15 +0800, Jason Lim wrote:
> By the way, I was wondering if FL needed any donated server(s) for
> building or testing packages? Or are we simply looking for download
> mirrors?

Right now we're pretty good.  We have a build server that handles i386
and I've got a x86_64 system that can build those updates when needed,
it just has to be shipped back to me from Duke.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jkeating at j2solutions.net  Wed Mar  2 16:42:32 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 02 Mar 2005 08:42:32 -0800
Subject: Can we get a zlib update?
In-Reply-To: <004a01c51f2e$c2f48a90$9100000a@M145Primary>
References: <015901c51ea9$4fadbe60$9100000a@M145Primary>
	<4224E5E8.7040304@shsu.edu><016701c51ead$2e54ebe0$9100000a@M145Primary>
	<1109716019.904.80.camel@jkeating2.hq.pogolinux.com>
	<002201c51ed0$051a2ec0$6601a8c0@vaio>
	<1109749569.13489.24.camel@localhost.localdomain>
	<004a01c51f2e$c2f48a90$9100000a@M145Primary>
Message-ID: <1109781752.904.111.camel@jkeating2.hq.pogolinux.com>

On Wed, 2005-03-02 at 08:50 -0500, Eric Wood wrote:
> I just think the version is artificially being kept down cause I don't
> see 
> any substatial diff in the code except for tab indents.

'substantial' diff?  I'm sorry, I don't deal in substantial.  If there
is ANYTHING different other than the security patches we applied to the
older rev, then there is not going to be an update.

> I'm fine, I just argue the point that the buck stops at zlib and it
> can 
> easily be kept up across all FC releases.

Why should the buck START with zlib?  If we do one, then we should do
them all right?  I'm sorry but this is a hard line I have to draw.  We
have a hard enough time keeping up with security backports we don't want
to add the burdon of upgrading everybody's pet package.  If you care
THAT much about it, nothing is stopping you from setting up your own
repository.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jimpop at yahoo.com  Wed Mar  2 17:08:03 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Wed, 02 Mar 2005 12:08:03 -0500
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <421E9E0E.1030000@videotron.ca>
References: <421E9E0E.1030000@videotron.ca>
Message-ID: <1109783284.7291.29.camel@blue>

I'm just wondering why this was sent out last Thursday but didn't make
it onto BugTRAQ until today.  Does anyone have any idea why there was
such a holdup on the announcement making it out?

-Jim P.

On Thu, 2005-02-24 at 22:39 -0500, Marc Deslauriers wrote:
> ---------------------------------------------------------------------
>                 Fedora Legacy Update Advisory
> 
> Synopsis:          Updated kernel packages fix security issues
> Advisory ID:       FLSA:2336
> Issue date:        2005-02-24
> Product:           Red Hat Linux, Fedora Core
> Keywords:          Bugfix
> Cross references:  https://bugzilla.fedora.us/show_bug.cgi?id=2336
> CVE Names:         CAN-2004-0177 CAN-2004-0685 CAN-2004-0814
>                     CAN-2004-0883 CAN-2004-0949 CAN-2004-1016
>                     CAN-2004-1017 CAN-2004-1056 CAN-2004-1068
>                     CAN-2004-1070 CAN-2004-1071 CAN-2004-1072
>                     CAN-2004-1073 CAN-2004-1074 CAN-2004-1137
>                     CAN-2004-1234 CAN-2004-1235 CAN-2005-0001
> ---------------------------------------------------------------------
> 
> 
> ---------------------------------------------------------------------
> 1. Topic:
> 
> Updated kernel packages that fix several security issues are now
> available.
> 
> The Linux kernel handles the basic functions of the operating system.
> 
> 2. Relevant releases/architectures:
> 
> Red Hat Linux 7.3 - i386
> Red Hat Linux 9 - i386
> Fedora Core 1 - i386
> 
> 3. Problem description:
> 
> This update includes fixes for several security issues:
> 
> The ext3 code in kernels before 2.4.26 did not properly initialize
> journal descriptor blocks. A privileged local user could read portions
> of kernel memory. The Common Vulnerabilities and Exposures project
> (cve.mitre.org) has assigned the name CAN-2004-0177 to this issue.
> 
> Conectiva discovered flaws in certain USB drivers affecting kernels
> prior to 2.4.27 which used the copy_to_user function on uninitialized
> structures. These flaws could allow local users to read small amounts
> of kernel memory. (CAN-2004-0685)
> 
> Multiple race conditions in the terminal layer could allow local users
> to obtain portions of kernel data via a TIOCSETD ioctl call to a
> terminal interface that is being accessed by another thread. This could
> also allow remote attackers to cause a denial of service (panic) by
> switching from console to PPP line discipline, then quickly sending data
> that is received during the switch. (CAN-2004-0814)
> 
> Stefan Esser discovered various flaws including buffer overflows in
> the smbfs driver affecting kernels prior to 2.4.28. A local user may be
> able to cause a denial of service (crash) or possibly gain privileges.
> In order to exploit these flaws the user would require control of
> a connected Samba server. (CAN-2004-0883, CAN-2004-0949)
> 
> ISEC security research and Georgi Guninski independantly discovered a
> flaw in the scm_send function in the auxiliary message layer. A local
> user could create a carefully crafted auxiliary message which could
> cause a denial of service (system hang). (CAN-2004-1016)
> 
> Multiple overflows were discovered and corrected in the io_edgeport
> driver. (CAN-2004-1017)
> 
> The Direct Rendering Manager (DRM) driver does not properly check the
> DMA lock, which could allow remote attackers or local users to cause a
> denial of service (X Server crash) and possibly modify the video output.
> (CAN-2004-1056)
> 
> A missing serialization flaw in unix_dgram_recvmsg was discovered that
> affects kernels prior to 2.4.28. A local user could potentially make
> use of a race condition in order to gain privileges. (CAN-2004-1068)
> 
> Paul Starzetz of iSEC discovered various flaws in the ELF binary loader
> affecting kernels prior to 2.4.28. A local user could use these flaws to
> gain read access to executable-only binaries or possibly gain
> privileges. (CAN-2004-1070, CAN-2004-1071, CAN-2004-1072, CAN-2004-1073,
> CAN-2004-1074)
> 
> ISEC security research discovered multiple vulnerabilities in the IGMP
> functionality of the kernels. These flaws could allow a local user to
> cause a denial of service (crash) or potentially gain privileges. Where
> multicast applications are being used on a system, these flaws may also
> allow remote users to cause a denial of service. (CAN-2004-1137)
> 
> Kirill Korotaev found a flaw in load_elf_binary affecting kernels prior
> to 2.4.26. A local user could create a carefully crafted binary in such
> a way that it would cause a denial of service (system crash).
> (CAN-2004-1234)
> 
> iSEC Security Research discovered a VMA handling flaw in the uselib(2)
> system call of the Linux kernel. A local user could make use of this
> flaw to gain elevated (root) privileges. (CAN-2004-1235)
> 
> iSEC Security Research discovered a flaw in the page fault handler code
> that could lead to local users gaining elevated (root) privileges on
> multiprocessor machines. (CAN-2005-0001)
> 
> All users are advised to upgrade their kernels to the packages
> associated with their machine architectures and configurations as listed
> in this erratum.
> 
> 4. Solution:
> 
> Before applying this update, make sure all previously released errata
> relevant to your system have been applied.
> 
> To install kernel packages manually, use "rpm -ivh <package>" and modify
> system settings to boot the kernel you have installed. To do this, edit
> /boot/grub/grub.conf and change the default entry to "default=0" (or, if
> you have chosen to use LILO as your boot loader, edit /etc/lilo.conf and
> run lilo)
> 
> Please note that this update is also available via yum and apt.  Many
> people find this an easier way to apply updates.  To use yum issue:
> 
> yum update
> 
> or to use apt:
> 
> apt-get update; apt-get upgrade
> 
> This will start an interactive process that will result in the
> appropriate RPMs being upgraded on your system.  This assumes that you
> have yum or apt-get configured for obtaining Fedora Legacy content.
> Please visit http://www.fedoralegacy.org/docs for directions on how to
> configure yum and apt-get.
> 
> Note that this may not automatically pull the new kernel in if you have
> configured apt/yum to ignore kernels. If so, follow the manual
> instructions above.
> 
> 5. Bug IDs fixed:
> 
> http://bugzilla.fedora.us - bug #2336 - Kernel bugs
> 
> 6. RPMs required:
> 
> Red Hat Linux 7.3:
> 
> SRPM:
> http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/kernel-2.4.20-42.7.legacy.src.rpm
> 
> i386:
> http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-42.7.legacy.i386.rpm
> http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-BOOT-2.4.20-42.7.legacy.i386.rpm
> http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-doc-2.4.20-42.7.legacy.i386.rpm
> http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-source-2.4.20-42.7.legacy.i386.rpm
> 
> i586:
> http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-42.7.legacy.i586.rpm
> http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-42.7.legacy.i586.rpm
> 
> i686:
> http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-42.7.legacy.i686.rpm
> http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-bigmem-2.4.20-42.7.legacy.i686.rpm
> http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-42.7.legacy.i686.rpm
> 
> athlon:
> http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-2.4.20-42.7.legacy.athlon.rpm
> http://download.fedoralegacy.org/redhat/7.3/updates/i386/kernel-smp-2.4.20-42.7.legacy.athlon.rpm
> 
> Red Hat Linux 9:
> 
> SRPM:
> http://download.fedoralegacy.org/redhat/9/updates/SRPMS/kernel-2.4.20-42.9.legacy.src.rpm
> 
> i386:
> http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-42.9.legacy.i386.rpm
> http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-BOOT-2.4.20-42.9.legacy.i386.rpm
> http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-doc-2.4.20-42.9.legacy.i386.rpm
> http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-source-2.4.20-42.9.legacy.i386.rpm
> 
> i586:
> http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-42.9.legacy.i586.rpm
> http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-smp-2.4.20-42.9.legacy.i586.rpm
> 
> i686:
> http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-42.9.legacy.i686.rpm
> http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-bigmem-2.4.20-42.9.legacy.i686.rpm
> http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-smp-2.4.20-42.9.legacy.i686.rpm
> 
> athlon:
> http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-2.4.20-42.9.legacy.athlon.rpm
> http://download.fedoralegacy.org/redhat/9/updates/i386/kernel-smp-2.4.20-42.9.legacy.athlon.rpm
> 
> Fedora Core 1:
> 
> SRPM:
> http://download.fedoralegacy.org/fedora/1/updates/SRPMS/kernel-2.4.22-1.2199.4.legacy.nptl.src.rpm
> 
> i386:
> http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2199.4.legacy.nptl.i386.rpm
> http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-doc-2.4.22-1.2199.4.legacy.nptl.i386.rpm
> http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-source-2.4.22-1.2199.4.legacy.nptl.i386.rpm
> 
> i586:
> http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2199.4.legacy.nptl.i586.rpm
> http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.4.legacy.nptl.i586.rpm
> 
> i686:
> http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2199.4.legacy.nptl.i686.rpm
> http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.4.legacy.nptl.i686.rpm
> 
> athlon:
> http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-2.4.22-1.2199.4.legacy.nptl.athlon.rpm
> http://download.fedoralegacy.org/fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.4.legacy.nptl.athlon.rpm
> 
> 7. Verification:
> 
> SHA1 sum                                 Package Name
> ---------------------------------------------------------------------
> 
> 7900b4d4608f6f23f1b19f8545a67bd733493c65 
> redhat/7.3/updates/i386/kernel-2.4.20-42.7.legacy.athlon.rpm
> dad7ced597c96a258e11d0de8437356ac82e40f3 
> redhat/7.3/updates/i386/kernel-2.4.20-42.7.legacy.i386.rpm
> caea6cb5c96897341c71e023e71d90b1b01bdde9 
> redhat/7.3/updates/i386/kernel-2.4.20-42.7.legacy.i586.rpm
> ffe552201b6bfdc5359596ae901bc249a365cec6 
> redhat/7.3/updates/i386/kernel-2.4.20-42.7.legacy.i686.rpm
> 4be06cfe9783c4d045fbfff4774e50f308fa6934 
> redhat/7.3/updates/i386/kernel-bigmem-2.4.20-42.7.legacy.i686.rpm
> 7d4b1b49e292ade40eb1f14e89338ae8df014981 
> redhat/7.3/updates/i386/kernel-BOOT-2.4.20-42.7.legacy.i386.rpm
> 6a17058770d6e6c2b8706232d1ceb60866b36ab0 
> redhat/7.3/updates/i386/kernel-doc-2.4.20-42.7.legacy.i386.rpm
> b8e1b78b834e48ec35906b3924eb2bd12a33e4d6 
> redhat/7.3/updates/i386/kernel-smp-2.4.20-42.7.legacy.athlon.rpm
> 55e2477c5ddd3934c2bfbc770ff0df7cce44a6a0 
> redhat/7.3/updates/i386/kernel-smp-2.4.20-42.7.legacy.i586.rpm
> c923851d4e460a672891db11bbc98089189a5a93 
> redhat/7.3/updates/i386/kernel-smp-2.4.20-42.7.legacy.i686.rpm
> dfcf9626635256e898e9696b7c8e58d826069be4 
> redhat/7.3/updates/i386/kernel-source-2.4.20-42.7.legacy.i386.rpm
> f4620b08ec8e2ae3973d5b3e555893ab3a7ce340 
> redhat/7.3/updates/SRPMS/kernel-2.4.20-42.7.legacy.src.rpm
> 2d6d73763d1d7631b61c40b8093757466dd24cd7 
> redhat/9/updates/i386/kernel-2.4.20-42.9.legacy.athlon.rpm
> 7b1f8f93eb586ae3fbe834670801d45b999700c2 
> redhat/9/updates/i386/kernel-2.4.20-42.9.legacy.i386.rpm
> 8d472f8c69a624b310758472c7f387c258f73c02 
> redhat/9/updates/i386/kernel-2.4.20-42.9.legacy.i586.rpm
> 618c079b5c9336a0bf0c4e7342616c001eea5f15 
> redhat/9/updates/i386/kernel-2.4.20-42.9.legacy.i686.rpm
> dcc66fd50b44cdb55c543d2d0496de595e627d7a 
> redhat/9/updates/i386/kernel-bigmem-2.4.20-42.9.legacy.i686.rpm
> d092d4efcc10b605fdf9724c5bd65560811063c4 
> redhat/9/updates/i386/kernel-BOOT-2.4.20-42.9.legacy.i386.rpm
> d99388a8d0f9b0b7e19aa61d25399dc4e5489427 
> redhat/9/updates/i386/kernel-doc-2.4.20-42.9.legacy.i386.rpm
> ccfaec93e1a5145ec9d91f0d3e7eeab19a3a81a4 
> redhat/9/updates/i386/kernel-smp-2.4.20-42.9.legacy.athlon.rpm
> 75e49f1b57037546407f3631a3c5f75fb2d671ee 
> redhat/9/updates/i386/kernel-smp-2.4.20-42.9.legacy.i586.rpm
> c7b63e8f26ccb8a237a5918d50e04b112e13f700 
> redhat/9/updates/i386/kernel-smp-2.4.20-42.9.legacy.i686.rpm
> f1e82fb01bcf318ee1e6d48ac3119ee8caa6be11 
> redhat/9/updates/i386/kernel-source-2.4.20-42.9.legacy.i386.rpm
> d11209f3d111ed3e633662c5f651772f11282f8e 
> redhat/9/updates/SRPMS/kernel-2.4.20-42.9.legacy.src.rpm
> 91df569f7f98a976f2686628c9a45160c8f730c6 
> fedora/1/updates/i386/kernel-2.4.22-1.2199.4.legacy.nptl.athlon.rpm
> 1ef2868a7a990521a080925ca81981cafa676258 
> fedora/1/updates/i386/kernel-2.4.22-1.2199.4.legacy.nptl.i586.rpm
> 5b093d72e5f7398f3b829c6ce557eb9817042732 
> fedora/1/updates/i386/kernel-2.4.22-1.2199.4.legacy.nptl.i686.rpm
> b66170a9431426138e454ddec7f3b98ec45a10fb 
> fedora/1/updates/i386/kernel-BOOT-2.4.22-1.2199.4.legacy.nptl.i386.rpm
> 4c5895f14271a8b5bc6e5489c053fba1f96e71f8 
> fedora/1/updates/i386/kernel-doc-2.4.22-1.2199.4.legacy.nptl.i386.rpm
> a358e368bea67f2cbbf32a6a1c9242e1cd7dffeb 
> fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.4.legacy.nptl.athlon.rpm
> c16b6217ac2ade811576e303a7eb1ddc0214d692 
> fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.4.legacy.nptl.i586.rpm
> d307317b04336c289cddde005e11c30b188119cb 
> fedora/1/updates/i386/kernel-smp-2.4.22-1.2199.4.legacy.nptl.i686.rpm
> 3b0301c812ad4379c6eb7bbd7970ab4f9602b37c 
> fedora/1/updates/i386/kernel-source-2.4.22-1.2199.4.legacy.nptl.i386.rpm
> d14e7971299e22a38cdeee145028d797ea477a1c 
> fedora/1/updates/SRPMS/kernel-2.4.22-1.2199.4.legacy.nptl.src.rpm
> 
> These packages are GPG signed by Fedora Legacy for security.  Our key is
> available from http://www.fedoralegacy org/about/security.php
> 
> You can verify each package with the following command:
> 
>      rpm --checksig -v <filename>
> 
> If you only wish to verify that each package has not been corrupted or
> tampered with, examine only the sha1sum with the following command:
> 
>      sha1sum <filename>
> 
> 8. References:
> 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0177
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0685
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0814
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0883
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0949
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1016
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1017
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1056
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1068
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1070
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1071
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1072
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1073
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1074
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1137
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1234
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1235
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0001
> 
> 9. Contact:
> 
> The Fedora Legacy security contact is <secnotice at fedoralegacy.org>. More
> project details at http://www.fedoralegacy.org
> 
> ---------------------------------------------------------------------
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list



From jkeating at j2solutions.net  Wed Mar  2 17:17:05 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 02 Mar 2005 09:17:05 -0800
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109783284.7291.29.camel@blue>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
Message-ID: <1109783825.904.119.camel@jkeating2.hq.pogolinux.com>

On Wed, 2005-03-02 at 12:08 -0500, Jim Popovitch wrote:
> I'm just wondering why this was sent out last Thursday but didn't make
> it onto BugTRAQ until today.  Does anyone have any idea why there was
> such a holdup on the announcement making it out?

Thats bugtraq for ya.  They are very slow at times to approve postings.
If this concerns you, please subscribe to the legacy-announce mailing
list.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From kelson at speed.net  Wed Mar  2 17:20:28 2005
From: kelson at speed.net (Kelson)
Date: Wed, 02 Mar 2005 09:20:28 -0800
Subject: Which PC to try FC2 on first?
In-Reply-To: <pan.2005.02.24.21.19.50.507647@adelphia.net>
References: <pan.2005.02.24.21.19.50.507647@adelphia.net>
Message-ID: <4225F5DC.4050607@speed.net>

beartooth wrote:
> So which machine would you try FC2 on first, and why? Or is a clean
> install the only way to get from FC1 to FC2 -- still? (I recall people
> here saying so when FC2 was newly out.) And in either case, how do I make
> sure when I get to the map machine that FC2 doesn't touch the XP part?

Anecdotal evidence to be sure, but I've got three machines I've upgraded 
from various Red Hat releases through FC3, and they all work fine.  Of 
course, I've been going one step at a time, but it shouldn't be a 
problem to go straight from FC1 to FC3.

As for protecting Windows XP from Fedora Core 2, you have two options. 
First, Google suggested this document: http://lwn.net/Articles/86835/ 
Second, I would expect (though I don't know for sure) that the problems 
with the FC2 installer have been fixed in FC3.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>



From dom at earth.li  Wed Mar  2 17:20:40 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Wed, 2 Mar 2005 17:20:40 +0000
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
Message-ID: <20050302172040.GI987@tirian.magd.ox.ac.uk>

On Wed, Mar 02, 2005 at 09:17:05AM -0800, Jesse Keating wrote:
> On Wed, 2005-03-02 at 12:08 -0500, Jim Popovitch wrote:
> > I'm just wondering why this was sent out last Thursday but didn't make
> > it onto BugTRAQ until today.  Does anyone have any idea why there was
> > such a holdup on the announcement making it out?
> 
> Thats bugtraq for ya.  They are very slow at times to approve postings.
> If this concerns you, please subscribe to the legacy-announce mailing
> list.

I believe he was talking about the copy sent to fedora-legacy-list.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



From jimpop at yahoo.com  Wed Mar  2 17:47:45 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Wed, 02 Mar 2005 12:47:45 -0500
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1109785665.7291.45.camel@blue>

On Wed, 2005-03-02 at 09:17 -0800, Jesse Keating wrote:
> Thats bugtraq for ya.  They are very slow at times to approve postings.
> If this concerns you, please subscribe to the legacy-announce mailing
> list.

That's not quite the reason i asked, but I already am subscribed to
both.  

The reason for asking is to better understand why BugTRAQ waited,
usually they do this pending some other data/info/contact for
verification/advanced-notification/etc.  I am (unfortunately) intimately
familiar with *TRAQ processes, delays, paper-work, proceedures.

I guess I could be more specific:  The reason I ask this is due to the
website being down a few weeks ago and nobody sent out anything to the
mailinglist during the days the outage was discussed on the mailinglist.
It took user interaction, with external folks (Verio, Vidyut, etc)
before anything was learned.  Was BugTRAQ waiting on anyone at FL prior
to releasing the notice to the wild?  

-Jim P.




From michal at harddata.com  Wed Mar  2 17:48:16 2005
From: michal at harddata.com (Michal Jaegermann)
Date: Wed, 2 Mar 2005 10:48:16 -0700
Subject: Which PC to try FC2 on first?
In-Reply-To: <4225F5DC.4050607@speed.net>;
	from kelson@speed.net on Wed, Mar 02, 2005 at 09:20:28AM -0800
References: <pan.2005.02.24.21.19.50.507647@adelphia.net>
	<4225F5DC.4050607@speed.net>
Message-ID: <20050302104816.A15178@mail.harddata.com>

On Wed, Mar 02, 2005 at 09:20:28AM -0800, Kelson wrote:
> 
> Anecdotal evidence to be sure, but I've got three machines I've upgraded 
> from various Red Hat releases through FC3, and they all work fine.  Of 
> course, I've been going one step at a time, but it shouldn't be a 
> problem to go straight from FC1 to FC3.

Not so long time ago I was running an upgrade from RH7.3 to FC3.
This was a non-event and most likely this would be the same even
for much earlier RH installations provided you are not cramped on
a disk space.

An /etc/X11/X link is _not_ switched automatically to Xorg binary,
so boot into a level 3 and do that yourself, and mostly /etc/ tree
should be cleaned from various *.rpmsave and *.rpmnew which may
require some thought from time to time.  A removal of obsolete/unwanted
packages may be also a good idea.  Do 'rpm -qa --last' and walk through
a resulting list by date.

That is about it.

   Michal



From madlists at teaparty.net  Wed Mar  2 18:13:32 2005
From: madlists at teaparty.net (Tom Yates)
Date: Wed, 2 Mar 2005 18:13:32 +0000 (GMT)
Subject: Can we get a zlib update?
In-Reply-To: <1109781752.904.111.camel@jkeating2.hq.pogolinux.com>
References: <015901c51ea9$4fadbe60$9100000a@M145Primary>
	<4224E5E8.7040304@shsu.edu><016701c51ead$2e54ebe0$9100000a@M145Primary>
	<1109716019.904.80.camel@jkeating2.hq.pogolinux.com>
	<002201c51ed0$051a2ec0$6601a8c0@vaio>
	<1109749569.13489.24.camel@localhost.localdomain>
	<004a01c51f2e$c2f48a90$9100000a@M145Primary>
	<1109781752.904.111.camel@jkeating2.hq.pogolinux.com>
Message-ID: <Pine.LNX.4.61.0503021805130.15659@risby.gatekeeper.ltd.uk>

On Wed, 2 Mar 2005, Jesse Keating wrote:

> Why should the buck START with zlib?  If we do one, then we should do
> them all right?  I'm sorry but this is a hard line I have to draw.

fwiw, i wholeheartedly support jesse on this.

i think it's been fairly well established that zlib doesn't need upgrading 
to build ClamAV, but even if we were discussing some deep core tool, 
without whose upgrade no single piece of code released anywhere on earth 
since 1.1.2003 would build, i'd still support the "we patch, not upgrade" 
policy.

i'm maintaining production servers on the strength of FL, and i do *not* 
want stuff changing under me without my consent.  where i need new 
functionality (as i do, for (eg) squirrelmail and spamassassin), i'll 
package it myself.  unless i choose to do that, or to bite the bullet and 
upgrade an entire system, i *really* don't want upgrades disguised as 
fixes sneaking in under the radar.


-- 

   Tom Yates
   Cambridge, UK.



From jkeating at j2solutions.net  Wed Mar  2 18:29:30 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 02 Mar 2005 10:29:30 -0800
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109785665.7291.45.camel@blue>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
Message-ID: <1109788170.904.129.camel@jkeating2.hq.pogolinux.com>

On Wed, 2005-03-02 at 12:47 -0500, Jim Popovitch wrote:
> That's not quite the reason i asked, but I already am subscribed to
> both.  

Ok.

> The reason for asking is to better understand why BugTRAQ waited,
> usually they do this pending some other data/info/contact for
> verification/advanced-notification/etc.  I am (unfortunately)
> intimately
> familiar with *TRAQ processes, delays, paper-work, proceedures.

Sure.

> I guess I could be more specific:  The reason I ask this is due to the
> website being down a few weeks ago and nobody sent out anything to the
> mailinglist during the days the outage was discussed on the
> mailinglist.

I can't grok this very well... what are you saying here?

> It took user interaction, with external folks (Verio, Vidyut, etc)

What user interaction?  Vidyut is the DNS provider, Verio is the
registrar, etc?

> before anything was learned.  Was BugTRAQ waiting on anyone at FL
> prior
> to releasing the notice to the wild?

Not that I'm aware of.  I was never contacted by them.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jimpop at yahoo.com  Wed Mar  2 18:35:37 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Wed, 02 Mar 2005 13:35:37 -0500
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1109788537.8998.6.camel@blue>

On Wed, 2005-03-02 at 10:29 -0800, Jesse Keating wrote:
> > I guess I could be more specific:  The reason I ask this is due to the
> > website being down a few weeks ago and nobody sent out anything to the
> > mailinglist during the days the outage was discussed on the
> > mailinglist.
> 
> I can't grok this very well... what are you saying here?

The folks on the discussion mailinglist discussed the FL website being
down for days, even wondering if something happened to Jesse.  I had to
call Vidyut (got his number from whois) and he explained that there was
a DNS issue/move.  I then sent an email to everyone on the mailinglists
letting them know what I had found out.  I personally think it would
have been nice to hear about it from those involved with the DNS issues
rather than have to go figure it out myself.  Just my $.032

-Jim P.





From eric at interplas.com  Wed Mar  2 18:41:37 2005
From: eric at interplas.com (Eric Wood)
Date: Wed, 2 Mar 2005 13:41:37 -0500
Subject: Can we get a zlib update?
References: <015901c51ea9$4fadbe60$9100000a@M145Primary><4224E5E8.7040304@shsu.edu><016701c51ead$2e54ebe0$9100000a@M145Primary><1109716019.904.80.camel@jkeating2.hq.pogolinux.com><002201c51ed0$051a2ec0$6601a8c0@vaio><1109749569.13489.24.camel@localhost.localdomain><004a01c51f2e$c2f48a90$9100000a@M145Primary><1109781752.904.111.camel@jkeating2.hq.pogolinux.com>
	<Pine.LNX.4.61.0503021805130.15659@risby.gatekeeper.ltd.uk>
Message-ID: <00e501c51f57$77b67830$9100000a@M145Primary>

----- Original Message ----- 
From: "Tom Yates"
> fwiw, i wholeheartedly support jesse on this.
>
> i think it's been fairly well established that zlib doesn't need upgrading 
> to build ClamAV, but even if we were discussing some deep core tool, 
> without whose upgrade no single piece of code released anywhere on earth 
> since 1.1.2003 would build, i'd still support the "we patch, not upgrade" 
> policy.

And I agree with both of you on 99.9% of all packages.

I know I won't win this debate because of the "patch, not upgrade" rule - I 
was just hoping zlib would be kept more prestine for such a minor point 
release.

-eric wood



From jkeating at j2solutions.net  Wed Mar  2 18:46:08 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 02 Mar 2005 10:46:08 -0800
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109788537.8998.6.camel@blue>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
Message-ID: <1109789168.904.139.camel@jkeating2.hq.pogolinux.com>

On Wed, 2005-03-02 at 13:35 -0500, Jim Popovitch wrote:
> The folks on the discussion mailinglist discussed the FL website being
> down for days, even wondering if something happened to Jesse.  I had
> to
> call Vidyut (got his number from whois) and he explained that there
> was
> a DNS issue/move.  I then sent an email to everyone on the
> mailinglists
> letting them know what I had found out.  I personally think it would
> have been nice to hear about it from those involved with the DNS
> issues
> rather than have to go figure it out myself.  Just my $.032

The DNS outage effected my personal email as well, so A) I couldn't
check mail, and B) I couldn't send mail.  I would have if I could.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From balay at fastmail.fm  Wed Mar  2 18:58:20 2005
From: balay at fastmail.fm (Satish Balay)
Date: Wed, 2 Mar 2005 12:58:20 -0600 (CST)
Subject: Which PC to try FC2 on first?
In-Reply-To: <20050302104816.A15178@mail.harddata.com>
References: <pan.2005.02.24.21.19.50.507647@adelphia.net>
	<4225F5DC.4050607@speed.net>
	<20050302104816.A15178@mail.harddata.com>
Message-ID: <Pine.LNX.4.62.0503021257320.21808@asterix>

On Wed, 2 Mar 2005, Michal Jaegermann wrote:

> A removal of obsolete/unwanted packages may be also a good idea.  Do
> 'rpm -qa --last' and walk through a resulting list by date.

'yum list extras' is a nice way to identify such packages.

Satish



From jimpop at yahoo.com  Wed Mar  2 19:08:25 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Wed, 02 Mar 2005 14:08:25 -0500
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1109790506.9243.5.camel@blue>

On Wed, 2005-03-02 at 10:46 -0800, Jesse Keating wrote:
>
> The DNS outage effected my personal email as well, so A) I couldn't
> check mail, and B) I couldn't send mail.  I would have if I could.

At the risk of sounding like an absolute ass....  your personal email is
the only way that you can communicate?  If so, then FL needs to dedicate
an alternate leader to take over every time your personal email heads
south.  Seriously, did you not think that gmail, yahoo, or any other
free email provider would work?  What about asking someone on IRC to
post an update?  Clearly, as I saw it, the people on the mailinglist
were left high and dry to sort it out themselves.  Shame on FL.

-Jim P.





From skvidal at phy.duke.edu  Wed Mar  2 19:15:21 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 02 Mar 2005 14:15:21 -0500
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109790506.9243.5.camel@blue>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
Message-ID: <1109790921.14561.30.camel@cutter>



>At the risk of sounding like an absolute ass....  


well you took the risk, and it happened.

you sound like an ass.

-sv

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050302/8b78df37/attachment.htm>

From jimpop at yahoo.com  Wed Mar  2 19:14:31 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Wed, 02 Mar 2005 14:14:31 -0500
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109790921.14561.30.camel@cutter>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>  <1109790921.14561.30.camel@cutter>
Message-ID: <1109790872.9243.12.camel@blue>

On Wed, 2005-03-02 at 14:15 -0500, seth vidal wrote:
> 
> > At the risk of sounding like an absolute ass....  
> 
> well you took the risk, and it happened.
> 
> you sound like an ass.

And rightfully so too.

-Jim P.







From jkeating at j2solutions.net  Wed Mar  2 20:05:03 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 02 Mar 2005 12:05:03 -0800
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109790506.9243.5.camel@blue>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
Message-ID: <1109793903.904.157.camel@jkeating2.hq.pogolinux.com>

On Wed, 2005-03-02 at 14:08 -0500, Jim Popovitch wrote:
> At the risk of sounding like an absolute ass....  your personal email
> is
> the only way that you can communicate?  If so, then FL needs to
> dedicate
> an alternate leader to take over every time your personal email heads
> south.  Seriously, did you not think that gmail, yahoo, or any other
> free email provider would work?  What about asking someone on IRC to
> post an update?  Clearly, as I saw it, the people on the mailinglist
> were left high and dry to sort it out themselves.  Shame on FL.

Oh, I communicated in the IRC channel, to the builders, and anybody that
happened along.  I had assumed that if any questions came up on the list
during the time I couldn't easily check w/ my mail client that answers
would have been made.  No, I didn't take the time to read through the
web archives, I was busy fighting with Verio and the like to get my shit
taken care of, as well as trying to handle my day job.

I was available through IRC, I was available through my work email, I
was available through my work phone, if you were really concerned you
could have called.  Instead of spending effort to say that we're down
and working on it (people already KNEW we were down, and people DID know
I was working on it), I chose instead to WORK on it.

Now I've spent even MORE effort trying to stay calm and answer your
statements, when instead I could have been doing something far more
constructive, like spearheading our migration over to Red Hat's bugzilla
system, fixing some build scripts, allocating our x86_64 build system,
discussing our CVS commit access for FC trees etc...  Are you done now?
Can I go back to doing things that matter?

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jimpop at yahoo.com  Wed Mar  2 20:34:51 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Wed, 02 Mar 2005 15:34:51 -0500
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1109795691.9243.31.camel@blue>

On Wed, 2005-03-02 at 12:05 -0800, Jesse Keating wrote:
>
> Oh, I communicated in the IRC channel, to the builders, and anybody that
> happened along.  I had assumed that if any questions came up on the list
> during the time I couldn't easily check w/ my mail client that answers
> would have been made.  No, I didn't take the time to read through the
> web archives, I was busy fighting with Verio and the like to get my shit
> taken care of, as well as trying to handle my day job.
> 
> I was available through IRC, I was available through my work email, I
> was available through my work phone, if you were really concerned you
> could have called.  

How?  You are assuming that everyone on the mailinglist knew you were on
IRC (not everyone uses that, only the core people seem to), or that they
know your work email or phone (i haven't a clue what you do for work,
nor do i really care).  The point is the onus was on YOU to communicate
after the issue was raised, not the other way around.

> Instead of spending effort to say that we're down and working on it 
> (people already KNEW we were down, and people DID know I was working 
> on it), I chose instead to WORK on it.

BINGO!  Your definition of who knew is different than mine.  You
*thought* everyone knew when in fact they didn't.  Yes some people did
know, those people should have stepped up to the plate and told the
mailinglist as well.  Is this the Jesse Legacy project or is this a
larger team effort?  You, Jesse Keating, don't need to be doing
everything, there needs to be some *organized* structure for FL to
endure.

> Now I've spent even MORE effort trying to stay calm and answer your
> statements, when instead I could have been doing something far more
> constructive, like spearheading our migration over to Red Hat's bugzilla
> system, fixing some build scripts, allocating our x86_64 build system,
> discussing our CVS commit access for FC trees etc...  Are you done now?
> Can I go back to doing things that matter?

Frankly, I would rather see you delegate some responsibility to others
and then you take some time to define and setup an organization before
doing anything else.  As I said before you can't be the chief cook and
bottle washer too.  Going forward please communicate to the mailinglist
or let the mailinglist know that you don't consider it worthy of keeping
informed.  In my opinion the crux of FL should be discussed and
announced on the mailinglists first.

-Jim P.






From jkeating at j2solutions.net  Wed Mar  2 21:10:44 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 02 Mar 2005 13:10:44 -0800
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109795691.9243.31.camel@blue>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
Message-ID: <1109797844.904.171.camel@jkeating2.hq.pogolinux.com>

On Wed, 2005-03-02 at 15:34 -0500, Jim Popovitch wrote:
> How?  You are assuming that everyone on the mailinglist knew you were
> on
> IRC (not everyone uses that, only the core people seem to), or that
> they
> know your work email or phone (i haven't a clue what you do for work,
> nor do i really care).  The point is the onus was on YOU to
> communicate
> after the issue was raised, not the other way around.

The people that really needed to know, the builders and such, they knew
where to find me and got informed rather quickly.  There is no onus.
Are you paying me money to produce these updates?  Are you paying me
money to keep the webserver up and working?  Did I somehow enter into a
contract that states that you must be kept informed of everything that
happens around the project?  I didn't think so.  Get off it already.
The outage was supposed to have been for a day, then I was told it was
only the next day, then the next.  Then it came up and sending anything
out was a moot point anyway.

> > Instead of spending effort to say that we're down and working on it 
> > (people already KNEW we were down, and people DID know I was
> working 
> > on it), I chose instead to WORK on it.
> 
> BINGO!  Your definition of who knew is different than mine.  You
> *thought* everyone knew when in fact they didn't.  Yes some people did
> know, those people should have stepped up to the plate and told the
> mailinglist as well.  Is this the Jesse Legacy project or is this a
> larger team effort?  You, Jesse Keating, don't need to be doing
> everything, there needs to be some *organized* structure for FL to
> endure.

I don't do everything, not any more.  I haven't for quite a while.
There is a web developer, and no less than 3 people with build and
commit rights to packages.  In fact, I haven't touched a package in
probably over a year.  I'm trying to handle all the higher level things
like server maintainince, Red Hat interaction, FUD defending, hardware
allocation, and some script writing so that the people testing and
building packages can continue to do that with little interruption.

> > Now I've spent even MORE effort trying to stay calm and answer your
> > statements, when instead I could have been doing something far more
> > constructive, like spearheading our migration over to Red Hat's
> bugzilla
> > system, fixing some build scripts, allocating our x86_64 build
> system,
> > discussing our CVS commit access for FC trees etc...  Are you done
> now?
> > Can I go back to doing things that matter?
> 
> Frankly, I would rather see you delegate some responsibility to others
> and then you take some time to define and setup an organization before
> doing anything else. 
> As I said before you can't be the chief cook and
> bottle washer too.  

When I started the project, there was nobody else.  I had to do it all.
I've been taking on help as I go along and will continue to do so.  I
cannot however stop everything while we figure out how to manage it.
Thats a disservice to the end users.  The nature of this game is to make
it up as you go along, and fix the f'd up things you made up in haste.
Thats what I'm doing now.  Deal with it.

> Going forward please communicate to the mailinglist
> or let the mailinglist know that you don't consider it worthy of
> keeping
> informed.  

Sure, I'll do my best to let the list know at every little fart that
goes on.  I'm sure the majority of people really care.

> In my opinion the crux of FL should be discussed and
> announced on the mailinglists first.

I'm sorry, where did it say this was a democracy?  If there is a
decision that I feel requires community input, I'll bring it here.  Not
for a vote, but for opinions that will help me make said decision.  If
you don't like this, you're welcome to start your own project.  Good
luck w/ that.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jimpop at yahoo.com  Wed Mar  2 21:26:14 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Wed, 02 Mar 2005 16:26:14 -0500
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
References: <421E9E0E.1030000@videotron.ca>  <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1109798774.9243.40.camel@blue>

The problem Jesse is that nobody is going to give you or FL much money,
or very much time, when you represent the project like you do below.

I want to help nore, even possibly contribute money, but I have to see
some organization first.  If you compare FL to Debian there are striking
real differences.  OK, so FL isn't a distro like Debian, it is still an
entity that needs some good organization, a charter, and some
professionalism.  Compare FL to any other entity that is trying to gain
some respect, there are things that need to happen that just aren't
happening with FL.

-Jim P.

On Wed, 2005-03-02 at 13:10 -0800, Jesse Keating wrote:
> On Wed, 2005-03-02 at 15:34 -0500, Jim Popovitch wrote:
> > How?  You are assuming that everyone on the mailinglist knew you were
> > on
> > IRC (not everyone uses that, only the core people seem to), or that
> > they
> > know your work email or phone (i haven't a clue what you do for work,
> > nor do i really care).  The point is the onus was on YOU to
> > communicate
> > after the issue was raised, not the other way around.
> 
> The people that really needed to know, the builders and such, they knew
> where to find me and got informed rather quickly.  There is no onus.
> Are you paying me money to produce these updates?  Are you paying me
> money to keep the webserver up and working?  Did I somehow enter into a
> contract that states that you must be kept informed of everything that
> happens around the project?  I didn't think so.  Get off it already.
> The outage was supposed to have been for a day, then I was told it was
> only the next day, then the next.  Then it came up and sending anything
> out was a moot point anyway.
> 
> > > Instead of spending effort to say that we're down and working on it 
> > > (people already KNEW we were down, and people DID know I was
> > working 
> > > on it), I chose instead to WORK on it.
> > 
> > BINGO!  Your definition of who knew is different than mine.  You
> > *thought* everyone knew when in fact they didn't.  Yes some people did
> > know, those people should have stepped up to the plate and told the
> > mailinglist as well.  Is this the Jesse Legacy project or is this a
> > larger team effort?  You, Jesse Keating, don't need to be doing
> > everything, there needs to be some *organized* structure for FL to
> > endure.
> 
> I don't do everything, not any more.  I haven't for quite a while.
> There is a web developer, and no less than 3 people with build and
> commit rights to packages.  In fact, I haven't touched a package in
> probably over a year.  I'm trying to handle all the higher level things
> like server maintainince, Red Hat interaction, FUD defending, hardware
> allocation, and some script writing so that the people testing and
> building packages can continue to do that with little interruption.
> 
> > > Now I've spent even MORE effort trying to stay calm and answer your
> > > statements, when instead I could have been doing something far more
> > > constructive, like spearheading our migration over to Red Hat's
> > bugzilla
> > > system, fixing some build scripts, allocating our x86_64 build
> > system,
> > > discussing our CVS commit access for FC trees etc...  Are you done
> > now?
> > > Can I go back to doing things that matter?
> > 
> > Frankly, I would rather see you delegate some responsibility to others
> > and then you take some time to define and setup an organization before
> > doing anything else. 
> > As I said before you can't be the chief cook and
> > bottle washer too.  
> 
> When I started the project, there was nobody else.  I had to do it all.
> I've been taking on help as I go along and will continue to do so.  I
> cannot however stop everything while we figure out how to manage it.
> Thats a disservice to the end users.  The nature of this game is to make
> it up as you go along, and fix the f'd up things you made up in haste.
> Thats what I'm doing now.  Deal with it.
> 
> > Going forward please communicate to the mailinglist
> > or let the mailinglist know that you don't consider it worthy of
> > keeping
> > informed.  
> 
> Sure, I'll do my best to let the list know at every little fart that
> goes on.  I'm sure the majority of people really care.
> 
> > In my opinion the crux of FL should be discussed and
> > announced on the mailinglists first.
> 
> I'm sorry, where did it say this was a democracy?  If there is a
> decision that I feel requires community input, I'll bring it here.  Not
> for a vote, but for opinions that will help me make said decision.  If
> you don't like this, you're welcome to start your own project.  Good
> luck w/ that.
> 
> -- 
> Jesse Keating RHCE      (geek.j2solutions.net)
> Fedora Legacy Team      (www.fedoralegacy.org)
> GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
>  
> Was I helpful?  Let others know:
>  http://svcs.affero.net/rm.php?r=jkeating
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list



From rostetter at mail.utexas.edu  Wed Mar  2 23:25:24 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Wed,  2 Mar 2005 17:25:24 -0600
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1109805924.4e87054ef8512@mail.ph.utexas.edu>

Quoting Jesse Keating <jkeating at j2solutions.net>:

> On Wed, 2005-03-02 at 15:34 -0500, Jim Popovitch wrote:

> > In my opinion the crux of FL should be discussed and
> > announced on the mailinglists first.
> 
> I'm sorry, where did it say this was a democracy?  If there is a

I'd love for this to be *more* like an *ideal* democratic process.  But the
problem with this project is the same as the problem with most large 
democratic groups: apathy.

For example, the main page of the web site has for about 11 months read:

> A rewrite of the Fedora Legacy Project Overview is in progress at 
> http://www.fedoralegacy.org/wiki/index.php/UpdatedOverview. Everyone is 
> encouraged to read it and participate by submitting comments, suggestions, and
> other feedback via the wiki, or via e-mail to fedora-legacy-list at redhat.com. 

Guess how many people have sent any comments, updated the wiki page, suggested
we adopt it as-is,  other wise shown any interest in this?  Not one.  Not
a single person.  No one.  Nada.  You get the idea.

The main problem I have with people expecting so much from the project is
that almost no one seems to even care to take the time to help in even 
the most trivial ways.

> decision that I feel requires community input, I'll bring it here.  Not
> for a vote, but for opinions that will help me make said decision.  If

And most likely you will either get no answer, or just conflicting arguments
from which nothing is settled, if past history holds true.

> you don't like this, you're welcome to start your own project.  Good
> luck w/ that.

*grin* 

This really is a great project, dispite the small number of active participants.
I don't think any better project could be created to do this function.  There
simply are not enough interested people to support another project to the
level of support FL has achieved.

That's not to say we're doing fine.  But I think we're doing as good as we
can without more people deciding to join in and help.  People always say
"I'd like to help but I don't know how."  Well, read the Updated Overview
and let us know what you think about it!  It isn't that hard, and you 
would be helping.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Wed Mar  2 23:35:38 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Wed,  2 Mar 2005 17:35:38 -0600
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109798774.9243.40.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109798774.9243.40.camel@blue>
Message-ID: <1109806538.e8fda8b8d3267@mail.ph.utexas.edu>

Quoting Jim Popovitch <jimpop at yahoo.com>:

> The problem Jesse is that nobody is going to give you or FL much money,

Jesse has continually said we're not hurting for money/servers/etc. but
rather for participation.

> or very much time, when you represent the project like you do below.

While I know where you are going, you're not getting there.  You need
to change your tactics.

If more people did give time, we'd be better able to keep folks informed
as you desire.  Catch-22 maybe, but that's the truth.

> I want to help nore, even possibly contribute money, but I have to see
> some organization first.

Then help form that organization.  Participate in the formation of it.

> If you compare FL to Debian there are striking
> real differences.

Yes.  And if I compare Germany to France, there are some striking real
differences.

> OK, so FL isn't a distro like Debian, it is still an
> entity that needs some good organization, a charter, and some
> professionalism.

It has some organization, but needs more/better organization.  So why not
help to create it?

It has no real charter, but the "Overview" is as close to a charter as
we have, and defines to some extent the organization, so why not help us
by checking out the 11 month old revision of it as requested on the web
site?

It has a decent level of professionalism.  I'd like to see it higher.
But that is true of all open source projects I work on.  It is true
of the university I work for.  It is true of my local, state, and federal
governments.  The only way I can change that for any of these groups is
through pariticipation or litigation, and litigation won't work in most
cases (at least in the short term).

> Compare FL to any other entity that is trying to gain
> some respect, there are things that need to happen that just aren't
> happening with FL.

Hmmm...  I don't really see that.  Sorry.

> -Jim P.

-- 
Eric Rostetter



From jkeating at j2solutions.net  Wed Mar  2 23:43:05 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 02 Mar 2005 15:43:05 -0800
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109805924.4e87054ef8512@mail.ph.utexas.edu>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
Message-ID: <1109806985.904.202.camel@jkeating2.hq.pogolinux.com>

On Wed, 2005-03-02 at 17:25 -0600, Eric Rostetter wrote:
> I'd love for this to be *more* like an *ideal* democratic process.
> But the
> problem with this project is the same as the problem with most large 
> democratic groups: apathy.

True.  What I said was a little harsh.  Reality is that things that
really are serious decisions do get ran through the mail lists.

> For example, the main page of the web site has for about 11 months
> read:
> 
> > A rewrite of the Fedora Legacy Project Overview is in progress at 
> > http://www.fedoralegacy.org/wiki/index.php/UpdatedOverview. Everyone
> is 
> > encouraged to read it and participate by submitting comments,
> suggestions, and
> > other feedback via the wiki, or via e-mail to fedora-legacy-
> list at redhat.com. 
> 
> Guess how many people have sent any comments, updated the wiki page,
> suggested
> we adopt it as-is,  other wise shown any interest in this?  Not one.
> Not
> a single person.  No one.  Nada.  You get the idea.
> 
> The main problem I have with people expecting so much from the project
> is
> that almost no one seems to even care to take the time to help in
> even 
> the most trivial ways.

I see this too.  I'd love to not have to manage so much right now, to be
able to take time to clearly write out some things, to take a look at
the little things that would help.  All in due time I feel.  I'm slowly
able to make progress and thats better than nothing.  People like you
are helping more than you know.

> > decision that I feel requires community input, I'll bring it here.
> Not
> > for a vote, but for opinions that will help me make said decision.
> If
> 
> And most likely you will either get no answer, or just conflicting
> arguments
> from which nothing is settled, if past history holds true.

But at least I've made an effort.  This is what I mean by getting
opinions and arguments to help me make the decision.  Thats what
decision makers do, they listen to views and opinions, participate in
discussions, etc... and make decisions based upon the input and output.

> > you don't like this, you're welcome to start your own project.  Good
> > luck w/ that.
> 
> *grin* 
> 
> This really is a great project, dispite the small number of active
> participants.
> I don't think any better project could be created to do this function.
> There
> simply are not enough interested people to support another project to
> the
> level of support FL has achieved.
> 
> That's not to say we're doing fine.  But I think we're doing as good
> as we
> can without more people deciding to join in and help.  People always
> say
> "I'd like to help but I don't know how."  Well, read the Updated
> Overview
> and let us know what you think about it!  It isn't that hard, and you 
> would be helping.
> 
-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From goisman at physics.arizona.edu  Thu Mar  3 00:06:34 2005
From: goisman at physics.arizona.edu (Philip Goisman)
Date: Wed, 2 Mar 2005 17:06:34 -0700
Subject: FC1 legacy for x86_64
Message-ID: <200503030006.j2306YZf032645@bohr.physics.arizona.edu>

Hi,

	Correct me if I'm wrong, but I don't see legacy supporting
FC1 x86_64 systems.  If I'm wrong please direct me to where this
is documented.  I presently use http://fedoralegacy.org/docs/yum-fc1.php
for my FC1 386/586/686 systems.

	My apologies in advance if it's the same procedure except
for building gpg and yum from source on x86_64 systems.

Regards,

Philip



From jkeating at j2solutions.net  Thu Mar  3 00:17:09 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 02 Mar 2005 16:17:09 -0800
Subject: FC1 legacy for x86_64
In-Reply-To: <200503030006.j2306YZf032645@bohr.physics.arizona.edu>
References: <200503030006.j2306YZf032645@bohr.physics.arizona.edu>
Message-ID: <1109809029.904.206.camel@jkeating2.hq.pogolinux.com>

On Wed, 2005-03-02 at 17:06 -0700, Philip Goisman wrote:
> Hi,
> 
>         Correct me if I'm wrong, but I don't see legacy supporting
> FC1 x86_64 systems.  If I'm wrong please direct me to where this
> is documented.  I presently use http://fedoralegacy.org/docs/yum-
> fc1.php
> for my FC1 386/586/686 systems.
> 
>         My apologies in advance if it's the same procedure except
> for building gpg and yum from source on x86_64 systems.
> 
> 

At this time we don't support x86_64.  I'm working on getting another
build box and a build system that will work for x86_64.  Theoretically,
the Fedora Extras build software will come online rather soon, and I can
re-deploy our current build box so that it could handle both 32bit and
64bit package building.  Race condition, which will be done first?  (:

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jimpop at yahoo.com  Thu Mar  3 01:13:47 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Wed, 02 Mar 2005 20:13:47 -0500
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1109812427.10353.7.camel@blue>

On Wed, 2005-03-02 at 15:43 -0800, Jesse Keating wrote:

> True.  What I said was a little harsh.  Reality is that things that
> really are serious decisions do get ran through the mail lists.

Some of my comments were probably overly harsh.  In an effort get
something positive out of this discussion, let me continue with why it
is difficult for me to contribute more.  

Let's take "mc" as an issue.  I use Midnight Commander, and I see there
is some chatter about it in Bugzilla.  So, I go to bugzilla and search
for it it.... hmmm, 4 hits.  Which is the one that I should spend time
with?  Ok, so I pick one, looks like there isn't really a good consensus
from the deep level guys as to what to fix... this means there is
nothing for me to test.  Ok, so I wait.  Days pass.  Oh, looks like
there are now some pkgs to d/l and test.  What to test?  Where is the
details on what should be tested... go read CAN reports.   OK, now I
think I know what was broke, where do I go to determine what was fixed
so that I know what to test?   Oh well, I give up and just test the
stuff that I use in mc.   Great, all works (afaik), sha1sum and post a
VERIFY.  More days pass, more deep level comments about more mc issues
needing resolution.  The result: all the time I spent was a waste.

The FL process is painful, difficult, and makes people question whether
or not they even want to be involved. 

-Jim P.



From pekkas at netcore.fi  Thu Mar  3 05:57:00 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 3 Mar 2005 07:57:00 +0200 (EET)
Subject: FC1 legacy for x86_64
In-Reply-To: <1109809029.904.206.camel@jkeating2.hq.pogolinux.com>
References: <200503030006.j2306YZf032645@bohr.physics.arizona.edu>
	<1109809029.904.206.camel@jkeating2.hq.pogolinux.com>
Message-ID: <Pine.LNX.4.61.0503030756050.21221@netcore.fi>

On Wed, 2 Mar 2005, Jesse Keating wrote:
> At this time we don't support x86_64.  I'm working on getting another
> build box and a build system that will work for x86_64.  Theoretically,
> the Fedora Extras build software will come online rather soon, and I can
> re-deploy our current build box so that it could handle both 32bit and
> 64bit package building.  Race condition, which will be done first?  (:

As long as nobody needs to QA x86_64 packages, that's OK (i.e., they 
don't require +VERIFY or +PUBLISH votes).  It takes way too long to 
get those for i386 versions as it is..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From pekkas at netcore.fi  Thu Mar  3 06:06:15 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 3 Mar 2005 08:06:15 +0200 (EET)
Subject: how to get started with helping the project [...]
In-Reply-To: <1109812427.10353.7.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
Message-ID: <Pine.LNX.4.61.0503030757380.21221@netcore.fi>

On Wed, 2 Mar 2005, Jim Popovitch wrote:
> OK, now I
> think I know what was broke, where do I go to determine what was fixed
> so that I know what to test?   Oh well, I give up and just test the
> stuff that I use in mc.   Great, all works (afaik), sha1sum and post a
> VERIFY.  More days pass, more deep level comments about more mc issues
> needing resolution.  The result: all the time I spent was a waste.

Maybe the docs are not sufficiently clear how to "get started".  I've 
tried to improve them but without much success I guess.

First, take a look at:
   http://www.fedoralegacy.org/wiki/index.php/QaTesting

Decide how you'd like to help, basically:
  a) create packages to fix issues
  b) QA packages created by others to ("PUBLISH voting"), and/or
  c) QA packages in updates-testing ("VERIFY voting")

Then, take a look at (this is linked from /participate/):
  http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt

If a), look for packages with "needs investigation/work/packages"
If b), look under "NEEDS publish"
If c), look under "NEEDS verify" (for RHL/FC version you have)

I assume you'd like to do c), at least initially -- it's the easiest. 
Currently there are about 16 packages waiting for one or more VERIFY 
votes.  It would be really useful to try help with these.  VERIFYING 
is really trivial if you have ever used the application in question, 
and you have access to the right RHL/FC versions.

For how to do VERIFY testing, take another look at
  http://www.fedoralegacy.org/wiki/index.php/QaTesting under
  "Testing packages for release to updates".

It's really very simple!

Please, we REALLY need people to do QA -- _especially_ VERIFYing 
because it requires the right RHL/FC version and the possibility to 
quick-test an application.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From jkeating at j2solutions.net  Thu Mar  3 06:04:25 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 02 Mar 2005 22:04:25 -0800
Subject: FC1 legacy for x86_64
In-Reply-To: <Pine.LNX.4.61.0503030756050.21221@netcore.fi>
References: <200503030006.j2306YZf032645@bohr.physics.arizona.edu>
	<1109809029.904.206.camel@jkeating2.hq.pogolinux.com>
	<Pine.LNX.4.61.0503030756050.21221@netcore.fi>
Message-ID: <1109829866.19971.21.camel@localhost.localdomain>

On Thu, 2005-03-03 at 07:57 +0200, Pekka Savola wrote:
> As long as nobody needs to QA x86_64 packages, that's OK (i.e., they 
> don't require +VERIFY or +PUBLISH votes).  It takes way too long to 
> get those for i386 versions as it is..

I'm not really comfortable pushing updates w/out QA.  I suppose this is
where the community can chime in.  How many are on x86_64 that need
updates and are willing to QA?  How do you feel about QA on i386 being
enough to push the update on x86_64?

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050302/d6bc6048/attachment.sig>

From ingo at auroralinux.org  Thu Mar  3 08:59:31 2005
From: ingo at auroralinux.org (Ingo T. Storm)
Date: Thu, 03 Mar 2005 09:59:31 +0100
Subject: FC1 legacy for x86_64
In-Reply-To: <1109829866.19971.21.camel@localhost.localdomain>
References: <200503030006.j2306YZf032645@bohr.physics.arizona.edu>	<1109809029.904.206.camel@jkeating2.hq.pogolinux.com>	<Pine.LNX.4.61.0503030756050.21221@netcore.fi>
	<1109829866.19971.21.camel@localhost.localdomain>
Message-ID: <4226D1F3.6070407@auroralinux.org>

Jesse Keating wrote:

>How many are on x86_64 that need updates and are willing to QA?  
>
I only joined the x86_64 game with FC2 and due to the fact that it's 
pretty close to RHEL4 and ydl 4 that's where my time goes. I can only 
support one family;-)

>How do you feel about QA on i386 being enough to push the update on x86_64?
>  
>
not too good, but that should be up to the FC1/x86_64 users. Should work 
with a lot of stuff like httpd and the like, might break with the more 
arch specific stuff or due to tool chain issues..

Ingo



From jimpop at yahoo.com  Thu Mar  3 13:29:13 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 08:29:13 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <Pine.LNX.4.61.0503030757380.21221@netcore.fi>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
Message-ID: <1109856553.11173.15.camel@blue>

On Thu, 2005-03-03 at 08:06 +0200, Pekka Savola wrote:
> If c), look under "NEEDS verify" (for RHL/FC version you have)
> 
> I assume you'd like to do c), at least initially -- it's the easiest. 

It is NOT anywhere near easy.  Not by a long shot.  Thus the reason for
my speaking up.  There really needs to be a list of:
   
   What was broke
   The proposed fix
   Who fixed it
   What should be tested

> Currently there are about 16 packages waiting for one or more VERIFY 
> votes.  It would be really useful to try help with these.  VERIFYING 
> is really trivial if you have ever used the application in question, 
> and you have access to the right RHL/FC versions.

I do have access, I have "verified" packages (or have I? who decides?),
and I probably will continue at some level.  The problem is FL needs
more than just the current people and process, and what it being tested
needs more rigorous (think: ISO 9001) guidelines and procedures. 

> 
> For how to do VERIFY testing, take another look at
>   http://www.fedoralegacy.org/wiki/index.php/QaTesting under
>   "Testing packages for release to updates".

That URL is a start, but there is no second step after it.  Everyone has
read the above... where's the next chapter?

> 
> It's really very simple!

As I said;  It is NOT anything close to simple, and even then it is open
to too much discernment.  A *kernel* has been released recently..who
tested it in it's entirety?   Where is the list of fixes and the
checkmarks that indicate "x" was fixed by Bob and "x" was tested by Sue?

-Jim P.








From pekkas at netcore.fi  Thu Mar  3 16:10:30 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 3 Mar 2005 18:10:30 +0200 (EET)
Subject: what needs to be tested at VERIFY
In-Reply-To: <1109856553.11173.15.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
Message-ID: <Pine.LNX.4.61.0503031804001.2572@netcore.fi>

On Thu, 3 Mar 2005, Jim Popovitch wrote:
> It is NOT anywhere near easy.  Not by a long shot.  Thus the reason for
> my speaking up.  There really needs to be a list of:
>
>   What was broke
>   The proposed fix
>   Who fixed it

These should be available at the Fedora Legacy Test Notification mail? 
(the middle part, if you want it in unidiff, is available from 
comparing the sources.)

>   What should be tested

That's a good point, below.

>> Currently there are about 16 packages waiting for one or more VERIFY
>> votes.  It would be really useful to try help with these.  VERIFYING
>> is really trivial if you have ever used the application in question,
>> and you have access to the right RHL/FC versions.
>
> I do have access, I have "verified" packages (or have I? who decides?),
> and I probably will continue at some level.  The problem is FL needs
> more than just the current people and process, and what it being tested
> needs more rigorous (think: ISO 9001) guidelines and procedures.

That's exactly the problem, I think.

Different people have different things in mind when they think about 
"testing".

Mine is:
  - see that it installs
  - see that basic functionality works (5 or 10 minutes is enough)
  - if you are able to test the exploit, it's bonus but not necessary.

It seems clear that there is _NO_ way the project has resources for 
any _REAL_ QA testing.  So, we'll just have to be content with 
checking for the obvious issues (IMHO).

Otherwise we get nothing done, and that would be much worse.

>> For how to do VERIFY testing, take another look at
>>   http://www.fedoralegacy.org/wiki/index.php/QaTesting under
>>   "Testing packages for release to updates".
>
> That URL is a start, but there is no second step after it.  Everyone has
> read the above... where's the next chapter?

What would you like to see in the next chapter?  Discussion on what to 
test?  Something else?

> As I said;  It is NOT anything close to simple, and even then it is open
> to too much discernment.  A *kernel* has been released recently..who
> tested it in it's entirety?   Where is the list of fixes and the
> checkmarks that indicate "x" was fixed by Bob and "x" was tested by Sue?

>From above, I don't think the project has resources for this kind of 
testing.  It's IMHO enough to get a "warm fuzzy feeling", like "I 
installed it, the app still works, nothing seems to have broken."

There's no way we could do any more than that.  Besides, we're already 
using the patches from sources which have already had some QA (e.g., 
RHEL, Debian, ...) so they should not be typically broken.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From jkeating at j2solutions.net  Thu Mar  3 16:31:12 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 03 Mar 2005 08:31:12 -0800
Subject: how to get started with helping the project [...]
In-Reply-To: <1109856553.11173.15.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
Message-ID: <1109867472.4902.12.camel@localhost.localdomain>

On Thu, 2005-03-03 at 08:29 -0500, Jim Popovitch wrote:
> As I said;  It is NOT anything close to simple, and even then it is
> open
> to too much discernment.  A *kernel* has been released recently..who
> tested it in it's entirety?   Where is the list of fixes and the
> checkmarks that indicate "x" was fixed by Bob and "x" was tested by
> Sue?
> 
> -Jim P.

Wouldn't that be nice?  And wouldn't it be nice if we got a package out
w/out the current sometimes 4 month waiting period?  You do know that
Red Hat doesn't even have that complex of a QA system....

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/77db872c/attachment.sig>

From jimpop at yahoo.com  Thu Mar  3 17:24:23 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 12:24:23 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109867472.4902.12.camel@localhost.localdomain>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
	<1109867472.4902.12.camel@localhost.localdomain>
Message-ID: <1109870663.11173.33.camel@blue>

On Thu, 2005-03-03 at 08:31 -0800, Jesse Keating wrote:
> On Thu, 2005-03-03 at 08:29 -0500, Jim Popovitch wrote:
> > As I said;  It is NOT anything close to simple, and even then it is
> > open
> > to too much discernment.  A *kernel* has been released recently..who
> > tested it in it's entirety?   Where is the list of fixes and the
> > checkmarks that indicate "x" was fixed by Bob and "x" was tested by
> > Sue?
> > 
> > -Jim P.
> 
> Wouldn't that be nice?  And wouldn't it be nice if we got a package out
> w/out the current sometimes 4 month waiting period?  You do know that
> Red Hat doesn't even have that complex of a QA system....

Redhat EL has achieved EAL2 and COE certifications.  I seriously doubt
they did this using the same Q&A procedures that FL is using.  Wrt to
COE and EAL, there is no such developer statements like "wouldn't that
be nice" or "warm and fuzzy feeling".  EAL and COE necessitate exacting
procedures and processes, something RH seems to be excelling at.  

Add ISO 9001 into the discussion and your above description of RH Q&A
either reveals fraud within RH (wrt ISO 9001 compliance) or insight into
your lack of knowledge of RH operations.

-Jim P.






From sweller at ena.com  Thu Mar  3 17:31:06 2005
From: sweller at ena.com (Simon Weller)
Date: Thu, 03 Mar 2005 11:31:06 -0600
Subject: how to get started with helping the project [...]
In-Reply-To: <1109870663.11173.33.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
	<1109867472.4902.12.camel@localhost.localdomain>
	<1109870663.11173.33.camel@blue>
Message-ID: <1109871066.32681.10.camel@misdc02.ena.com>

Access was being rotated correctly, but it didn't appear that the error
log was.

Give it another go now.

- Si

On Thu, 2005-03-03 at 12:24 -0500, Jim Popovitch wrote:
> On Thu, 2005-03-03 at 08:31 -0800, Jesse Keating wrote:
> > On Thu, 2005-03-03 at 08:29 -0500, Jim Popovitch wrote:
> > > As I said;  It is NOT anything close to simple, and even then it is
> > > open
> > > to too much discernment.  A *kernel* has been released recently..who
> > > tested it in it's entirety?   Where is the list of fixes and the
> > > checkmarks that indicate "x" was fixed by Bob and "x" was tested by
> > > Sue?
> > > 
> > > -Jim P.
> > 
> > Wouldn't that be nice?  And wouldn't it be nice if we got a package out
> > w/out the current sometimes 4 month waiting period?  You do know that
> > Red Hat doesn't even have that complex of a QA system....
> 
> Redhat EL has achieved EAL2 and COE certifications.  I seriously doubt
> they did this using the same Q&A procedures that FL is using.  Wrt to
> COE and EAL, there is no such developer statements like "wouldn't that
> be nice" or "warm and fuzzy feeling".  EAL and COE necessitate exacting
> procedures and processes, something RH seems to be excelling at.  
> 
> Add ISO 9001 into the discussion and your above description of RH Q&A
> either reveals fraud within RH (wrt ISO 9001 compliance) or insight into
> your lack of knowledge of RH operations.
> 
> -Jim P.
> 
> 
> 
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
-- 



From sweller at ena.com  Thu Mar  3 17:32:33 2005
From: sweller at ena.com (Simon Weller)
Date: Thu, 03 Mar 2005 11:32:33 -0600
Subject: how to get started with helping the project [...]
In-Reply-To: <1109871066.32681.10.camel@misdc02.ena.com>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
	<1109867472.4902.12.camel@localhost.localdomain>
	<1109870663.11173.33.camel@blue>
	<1109871066.32681.10.camel@misdc02.ena.com>
Message-ID: <1109871153.32681.12.camel@misdc02.ena.com>

oops, not sure how I sent that to the list ;-)

Must be one of those days.

- Si

On Thu, 2005-03-03 at 11:31 -0600, Simon Weller wrote:
> Access was being rotated correctly, but it didn't appear that the error
> log was.
> 
> Give it another go now.
> 
> - Si
> 
> On Thu, 2005-03-03 at 12:24 -0500, Jim Popovitch wrote:
> > On Thu, 2005-03-03 at 08:31 -0800, Jesse Keating wrote:
> > > On Thu, 2005-03-03 at 08:29 -0500, Jim Popovitch wrote:
> > > > As I said;  It is NOT anything close to simple, and even then it is
> > > > open
> > > > to too much discernment.  A *kernel* has been released recently..who
> > > > tested it in it's entirety?   Where is the list of fixes and the
> > > > checkmarks that indicate "x" was fixed by Bob and "x" was tested by
> > > > Sue?
> > > > 
> > > > -Jim P.
> > > 
> > > Wouldn't that be nice?  And wouldn't it be nice if we got a package out
> > > w/out the current sometimes 4 month waiting period?  You do know that
> > > Red Hat doesn't even have that complex of a QA system....
> > 
> > Redhat EL has achieved EAL2 and COE certifications.  I seriously doubt
> > they did this using the same Q&A procedures that FL is using.  Wrt to
> > COE and EAL, there is no such developer statements like "wouldn't that
> > be nice" or "warm and fuzzy feeling".  EAL and COE necessitate exacting
> > procedures and processes, something RH seems to be excelling at.  
> > 
> > Add ISO 9001 into the discussion and your above description of RH Q&A
> > either reveals fraud within RH (wrt ISO 9001 compliance) or insight into
> > your lack of knowledge of RH operations.
> > 
> > -Jim P.
> > 
> > 
> > 
> > 
> > --
> > fedora-legacy-list mailing list
> > fedora-legacy-list at redhat.com
> > http://www.redhat.com/mailman/listinfo/fedora-legacy-list
-- 



From kelson at speed.net  Thu Mar  3 17:39:20 2005
From: kelson at speed.net (Kelson)
Date: Thu, 03 Mar 2005 09:39:20 -0800
Subject: Question re timing of "going legacy"
In-Reply-To: <200502251842.09517.carl.sopchak@cegis123.com>
References: <200502251842.09517.carl.sopchak@cegis123.com>
Message-ID: <42274BC8.1040308@speed.net>

Carl Sopchak wrote:
> I was wondering what the rationale was for moving FC<t-2> to Fedora Legacy 
> when FC<t> test2 release is announced.  (I.e., FC2 "going legacy" when FC4 
> test2 is released, as was also done with FC1/FC3.)  Is it the "push" / extra 
> resources required to get from test2 to final release?

I don't think this is really Fedora Legacy's decision.  Fedora Legacy 
just picks up a release when Fedora Core drops it.

As for why Fedora *Core* is dropping support for FC2 at one point and 
not another, that could more properly be answered over at one of their 
lists.  As I recall the original plan simply called for "two or three 
months" of updates past the release of the next version, in which case 
both FC1 and FC2 have gotten extra time.  I've always assumed that 
timing it to match a test release was a matter of picking something 
relevant rather than picking an arbitrary date.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>



From jkeating at j2solutions.net  Thu Mar  3 17:41:42 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 03 Mar 2005 09:41:42 -0800
Subject: how to get started with helping the project [...]
In-Reply-To: <1109870663.11173.33.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
	<1109867472.4902.12.camel@localhost.localdomain>
	<1109870663.11173.33.camel@blue>
Message-ID: <1109871702.4902.34.camel@localhost.localdomain>

On Thu, 2005-03-03 at 12:24 -0500, Jim Popovitch wrote:
> Redhat EL has achieved EAL2 and COE certifications.  I seriously doubt
> they did this using the same Q&A procedures that FL is using.  Wrt to
> COE and EAL, there is no such developer statements like "wouldn't that
> be nice" or "warm and fuzzy feeling".  EAL and COE necessitate
> exacting
> procedures and processes, something RH seems to be excelling at.  

Hey look, are we Red Hat Enterprise?  No.  Do we compete with Red Hat
Enterprise?  No.  Do we WANT to compete with Red Hat Enterprise?  No.
Please do NOT make that assumption.

> Add ISO 9001 into the discussion and your above description of RH Q&A
> either reveals fraud within RH (wrt ISO 9001 compliance) or insight
> into
> your lack of knowledge of RH operations.

RH QA processes for Enterprise products are NOT the same for Fedora
products.  Given that Fedora Legacy is about, um, lets see... FEDORA, my
statements are in fact true.

I'll state it again, loud and clear.  Fedora Legacy is NOT an
alternative to Red Hat Enterprise Linux.  It does not have the same
goal, it does not have the same features, it does not have the same
responsibility.  PERIOD.  If you require the features and goals of Red
Hat Enterprise, please USE Red Hat Enterprise, or one of it's rebuild
projects such as CentOS by the cAos group.

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/b5a42e2f/attachment.sig>

From jkeating at j2solutions.net  Thu Mar  3 17:44:10 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 03 Mar 2005 09:44:10 -0800
Subject: Question re timing of "going legacy"
In-Reply-To: <42274BC8.1040308@speed.net>
References: <200502251842.09517.carl.sopchak@cegis123.com>
	<42274BC8.1040308@speed.net>
Message-ID: <1109871850.4902.37.camel@localhost.localdomain>

On Thu, 2005-03-03 at 09:39 -0800, Kelson wrote:
> I don't think this is really Fedora Legacy's decision.  Fedora Legacy 
> just picks up a release when Fedora Core drops it.

Correct, however I was involved in picking the action date.  We figured
Test2 was a good time as any.  Gives us time where RH's systems won't be
completely bogged down w/ downloaders of a new release, so that we can
be fully up to speed even quicker.  As time progresses and Legacy is
involved even closer w/ Red Hat, there will likely be very little
'transition' work that has to be done.

> As for why Fedora *Core* is dropping support for FC2 at one point and 
> not another, that could more properly be answered over at one of
> their 
> lists.  As I recall the original plan simply called for "two or three 
> months" of updates past the release of the next version, in which
> case 
> both FC1 and FC2 have gotten extra time.  I've always assumed that 
> timing it to match a test release was a matter of picking something 
> relevant rather than picking an arbitrary date.

Right.  Dates are hard, but actions are easy to aim for.

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/c6aaf56a/attachment.sig>

From marcdeslauriers at videotron.ca  Thu Mar  3 17:46:09 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Thu, 03 Mar 2005 12:46:09 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109856553.11173.15.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
Message-ID: <1109871969.8226.4.camel@mdlinux>

On Thu, 2005-03-03 at 08:29 -0500, Jim Popovitch wrote:
> and I probably will continue at some level.  The problem is FL needs
> more than just the current people and process, and what it being tested
> needs more rigorous (think: ISO 9001) guidelines and procedures. 
> 

I think if more rigorous guidelines and procedures are what you're
looking for, clearly FL is not adequate for your needs and you should be
looking elsewhere.

> As I said;  It is NOT anything close to simple, and even then it is open
> to too much discernment.  A *kernel* has been released recently..who
> tested it in it's entirety?   Where is the list of fixes and the
> checkmarks that indicate "x" was fixed by Bob and "x" was tested by Sue?

Who tests the kernels that come out of kernel.org? Who tests Debian's
kernels? This is a community effort, if you want more extensive testing,
you'll have to do it yourself using your own set of guidelines and
procedures.

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/5f8018ac/attachment.sig>

From marcdeslauriers at videotron.ca  Thu Mar  3 17:51:23 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Thu, 03 Mar 2005 12:51:23 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109870663.11173.33.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
	<1109867472.4902.12.camel@localhost.localdomain>
	<1109870663.11173.33.camel@blue>
Message-ID: <1109872283.8226.9.camel@mdlinux>

On Thu, 2005-03-03 at 12:24 -0500, Jim Popovitch wrote:
> Redhat EL has achieved EAL2 and COE certifications.  I seriously doubt
> they did this using the same Q&A procedures that FL is using.  Wrt to
> COE and EAL, there is no such developer statements like "wouldn't that
> be nice" or "warm and fuzzy feeling".  EAL and COE necessitate exacting
> procedures and processes, something RH seems to be excelling at.  

That's why you should be buying Red Hat EL if you require the amount of
Q&A procedures you think they have in place.

> Add ISO 9001 into the discussion and your above description of RH Q&A
> either reveals fraud within RH (wrt ISO 9001 compliance) or insight into
> your lack of knowledge of RH operations.

Is RH actually ISO 9001?

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/730d5e5f/attachment.sig>

From jimpop at yahoo.com  Thu Mar  3 17:54:20 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 12:54:20 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109871702.4902.34.camel@localhost.localdomain>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
	<1109867472.4902.12.camel@localhost.localdomain>
	<1109870663.11173.33.camel@blue>
	<1109871702.4902.34.camel@localhost.localdomain>
Message-ID: <1109872461.11173.52.camel@blue>

On Thu, 2005-03-03 at 09:41 -0800, Jesse Keating wrote:
> I'll state it again, loud and clear.  Fedora Legacy is NOT an
> alternative to Red Hat Enterprise Linux.  It does not have the same
> goal, it does not have the same features, it does not have the same
> responsibility.  PERIOD.  

But FL does need to have the same *quality*.  Quality doesn't come
easily, and it's not something that should be taken lightly.  At the end
of the day I just want to contribute to a project that produces
something of quality, time and time again.  

Currently the complex puzzle, that FL calls a release, makes it
difficult for FL to grow, in fact I think it is driving people away.  Do
you want people to depend on FL or do you want them to participate only
to the point that they become convinced that paying RH or others is a
much better course.

-Jim P.



From jkeating at j2solutions.net  Thu Mar  3 17:59:30 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 03 Mar 2005 09:59:30 -0800
Subject: how to get started with helping the project [...]
In-Reply-To: <1109872461.11173.52.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
	<1109867472.4902.12.camel@localhost.localdomain>
	<1109870663.11173.33.camel@blue>
	<1109871702.4902.34.camel@localhost.localdomain>
	<1109872461.11173.52.camel@blue>
Message-ID: <1109872770.4902.50.camel@localhost.localdomain>

On Thu, 2005-03-03 at 12:54 -0500, Jim Popovitch wrote:
> But FL does need to have the same *quality*.  

No it doesn't.  FL can't have the same quality of RHEL w/out another Red
Hat backing it, and last time I checked, cloning isn't quite possible
yet.  I'm sorry, but thats just the way it is.  This is a COMMUNITY
project and you're going to get COMMUNITY quality.

> Quality doesn't come
> easily, and it's not something that should be taken lightly.

I'm not taking it lightly at all.  I'm trying to do the best we can,
realistically.

>   At the end
> of the day I just want to contribute to a project that produces
> something of quality, time and time again.  

Well, you'll just have to define your personal level of Quality
acceptance.  If you need a quality distro that has multi-year bugfixing
support, something close to RHEL quality, I seriously suggest you look
at joining the cAos project.  They could use the help.

> Currently the complex puzzle, that FL calls a release, makes it
> difficult for FL to grow, in fact I think it is driving people away.
> Do
> you want people to depend on FL or do you want them to participate
> only
> to the point that they become convinced that paying RH or others is a
> much better course.

I want people using FL to know what they're getting into, and to clearly
know what we're providing for them.  We're not an RHEL alternative.
We're a community project that's trying to provide security updates to
Legacy releases, for a short period of time.  There are plenty of people
(if my webusage logs don't lie) that want this exact thing, and I'm more
than happy to service them.  I cannot however service people properly
that want something else out of the project.

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/53321fac/attachment.sig>

From sebenste at weather.admin.niu.edu  Thu Mar  3 18:02:05 2005
From: sebenste at weather.admin.niu.edu (Gilbert Sebenste)
Date: Thu, 3 Mar 2005 12:02:05 -0600 (CST)
Subject: how to get started with helping the project [...]
In-Reply-To: <1109872461.11173.52.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
	<1109867472.4902.12.camel@localhost.localdomain>
	<1109870663.11173.33.camel@blue>
	<1109871702.4902.34.camel@localhost.localdomain>
	<1109872461.11173.52.camel@blue>
Message-ID: <Pine.LNX.4.58.0503031158150.2537@weather.admin.niu.edu>

On Thu, 3 Mar 2005, Jim Popovitch wrote:

> But FL does need to have the same *quality*.  Quality doesn't come
> easily, and it's not something that should be taken lightly.  At the end
> of the day I just want to contribute to a project that produces
> something of quality, time and time again.  

And it does, at a community level. Granted, the lateness of some of the 
updates due to the machine meltdown caused serious problems. But the 
actual updates themselves have been great, and updates are coming fast 
and furious now (for which I am grateful to our esteemed developers!!!).
 
> Currently the complex puzzle, that FL calls a release, makes it
> difficult for FL to grow, in fact I think it is driving people away.  Do
> you want people to depend on FL or do you want them to participate only
> to the point that they become convinced that paying RH or others is a
> much better course.

Again, you need to understand FL for what it is. It provides a good level 
of support, but it doesn't come out with a certified release 5 minutes 
after a bug is found. People should look at their needs and what FL 
provides. For some people, and you may be one of them, what is provided 
won't be enough to satisfy your needs. Others, like me, find what is 
provided to be satisfactory.

*******************************************************************************
Gilbert Sebenste                                                     ********
(My opinions only!)                                                  ******
Staff Meteorologist, Northern Illinois University                      ****
E-mail: sebenste at weather.admin.niu.edu                                  ***
web: http://weather.admin.niu.edu                                      **
Work phone: 815-753-5492                                                *
*******************************************************************************



From jimpop at yahoo.com  Thu Mar  3 18:04:25 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 13:04:25 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109871969.8226.4.camel@mdlinux>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>  <1109871969.8226.4.camel@mdlinux>
Message-ID: <1109873065.11173.59.camel@blue>

On Thu, 2005-03-03 at 12:46 -0500, Marc Deslauriers wrote:
> I think if more rigorous guidelines and procedures are what you're
> looking for, clearly FL is not adequate for your needs and you should be
> looking elsewhere.

Is that the image/statement that FL really truly believes in?  If so,
put it up on the main page of the website.

> Who tests the kernels that come out of kernel.org? 

kernel.org is source code that *may* make it into a distro.

> Who tests Debian's kernels? 

A pretty well organized community.  Debian.org lists who does what, and
who is responsible for what.  There is clearly a defined and easily
identifiable process there.

> This is a community effort, 

No it's not.  It's what 4 people, maybe 5 that really do stuff?
Shouldn't there be more?  If there is to be more, there needs to be more
structure and a better documented process, along with accountability.

> if you want more extensive testing, you'll have to do it yourself 
> using your own set of guidelines and procedures.

Put that on the main website too. 

-Jim P.







From jimpop at yahoo.com  Thu Mar  3 18:06:07 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 13:06:07 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <Pine.LNX.4.58.0503031158150.2537@weather.admin.niu.edu>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
	<1109867472.4902.12.camel@localhost.localdomain>
	<1109870663.11173.33.camel@blue>
	<1109871702.4902.34.camel@localhost.localdomain>
	<1109872461.11173.52.camel@blue>
	<Pine.LNX.4.58.0503031158150.2537@weather.admin.niu.edu>
Message-ID: <1109873167.11173.62.camel@blue>

On Thu, 2005-03-03 at 12:02 -0600, Gilbert Sebenste wrote:
> On Thu, 3 Mar 2005, Jim Popovitch wrote:
> 
> > But FL does need to have the same *quality*.  Quality doesn't come
> > easily, and it's not something that should be taken lightly.  At the end
> > of the day I just want to contribute to a project that produces
> > something of quality, time and time again.  
> 
> And it does, 

But wait, Jesse just said in a different email that it doesn't.  Which
is it?  WHERE IS IT DOCUMENTED?!?!?!?!

-Jim P.








From ad+lists at uni-x.org  Thu Mar  3 18:09:01 2005
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Thu, 03 Mar 2005 19:09:01 +0100
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <pan.2005.02.26.20.29.14.69654@adelphia.net>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
Message-ID: <1109873341.9846.447.camel@serendipity.dogma.lan>

Am Sa, den 26.02.2005 schrieb beartooth um 21:29:

> On at least one machine whose yum.conf used to work fine, I keep getting :
>                          =====
> Error: You may also check that you have the correct GPG keys installed
>                          =====
> whenever I try to run yum update.
> 
> It's Clint's sample file, which I don't *think* I recall touching, unless
> maybe to comment out one or two of the first things that seemed to be
> producing this. I did get GPG errors at first, until he kindly told me how
> to fix them. What has changed, and how do I cope?

Please tell us:

a) which GPG is claimed to be missing
b) for which packages from where (repository)
c) output of following single line command:
for key in $(rpm -qa | grep pubkey); do rpm -qi ${key} | head -10; done

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.14_FC2smp 
Serendipity 19:03:33 up 10 days, 6:12, load average: 0.35, 0.38, 0.32 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/0499623a/attachment.sig>

From jkeating at j2solutions.net  Thu Mar  3 18:12:40 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 03 Mar 2005 10:12:40 -0800
Subject: how to get started with helping the project [...]
In-Reply-To: <1109873167.11173.62.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
	<1109867472.4902.12.camel@localhost.localdomain>
	<1109870663.11173.33.camel@blue>
	<1109871702.4902.34.camel@localhost.localdomain>
	<1109872461.11173.52.camel@blue>
	<Pine.LNX.4.58.0503031158150.2537@weather.admin.niu.edu>
	<1109873167.11173.62.camel@blue>
Message-ID: <1109873560.4902.52.camel@localhost.localdomain>

On Thu, 2005-03-03 at 13:06 -0500, Jim Popovitch wrote:
> On Thu, 2005-03-03 at 12:02 -0600, Gilbert Sebenste wrote:
> > On Thu, 3 Mar 2005, Jim Popovitch wrote:
> > 
> > > But FL does need to have the same *quality*.  Quality doesn't come
> > > easily, and it's not something that should be taken lightly.  At
> the end
> > > of the day I just want to contribute to a project that produces
> > > something of quality, time and time again.  
> > 
> > And it does, 
> 
> But wait, Jesse just said in a different email that it doesn't.  Which
> is it?  WHERE IS IT DOCUMENTED?!?!?!?!

I guess it depends on what your definition of 'quality' is.  The
'quality' of work we produce currently is satisfactory (or nearly so)
for a majority of people.  It isn't however for you.  So, we're not
producing YOUR quality, but we are producing other people's quality.  Is
that clear enough?

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/082104f2/attachment.sig>

From jkeating at j2solutions.net  Thu Mar  3 18:20:17 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 03 Mar 2005 10:20:17 -0800
Subject: Call for help
Message-ID: <1109874017.4902.56.camel@localhost.localdomain>

Coming very soon, we'll be moving our bugs into Red Hat's bugzilla
system and living there.  There are many aspects to this move, including
migration of existing bugs, creating new accounts, re-assigning bugs to
proper components (now that we'll have them), and also rewriting all our
policies and guidelines.

I'm calling for a volunteer to parse through our wiki system and
website, and report back all the places we reference the Fedora.us
bugzilla system, and reference bug filing policy in general.  All of
these pages will have to be updated.  We don't have the new policy
written or decided just yet, this depends on some aspects and
limitations of Red Hat's bugzilla system.  However if we have a list of
whats out there currently, it would help us a lot when making new
policy.

Can anybody step up to the challenge?

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/a1a64684/attachment.sig>

From jimpop at yahoo.com  Thu Mar  3 18:26:10 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 13:26:10 -0500
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <pan.2005.02.26.20.29.14.69654@adelphia.net>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
Message-ID: <1109874371.11173.68.camel@blue>


Do this:
   gpg --list-keys

If you don't see 2 keys (Fedora Legacy and Red Hat, Inc) then do this:

   gpg --import /usr/share/doc/yum-1.0.3/RPM-GPG-KEY
   gpg --import /usr/share/doc/yum-1.0.3/Fedora-Legacy-GPG-KEY

If that doesn't work

   rm -rf /root/.gnupg
   (repeat above)

hth,

-Jim P.

On Sat, 2005-02-26 at 15:29 -0500, beartooth wrote:
> On at least one machine whose yum.conf used to work fine, I keep getting :
>                          =====
> Error: You may also check that you have the correct GPG keys installed
>                          =====
> whenever I try to run yum update.
> 
> It's Clint's sample file, which I don't *think* I recall touching, unless
> maybe to comment out one or two of the first things that seemed to be
> producing this. I did get GPG errors at first, until he kindly told me how
> to fix them. What has changed, and how do I cope?
> 



From steffen.grunewald at aei.mpg.de  Thu Mar  3 18:28:26 2005
From: steffen.grunewald at aei.mpg.de (Steffen Grunewald)
Date: Thu, 3 Mar 2005 19:28:26 +0100
Subject: Call for help
In-Reply-To: <1109874017.4902.56.camel@localhost.localdomain>
References: <1109874017.4902.56.camel@localhost.localdomain>
Message-ID: <20050303182825.GV14494@debian-server.aei.mpg.de>

On Thu, Mar 03, 2005 at 10:20:17AM -0800, Jesse Keating wrote:
> I'm calling for a volunteer to parse through our wiki system and
> website, and report back all the places we reference the Fedora.us
> bugzilla system, and reference bug filing policy in general.  All of
> these pages will have to be updated.  We don't have the new policy
> written or decided just yet, this depends on some aspects and
> limitations of Red Hat's bugzilla system.  However if we have a list of
> whats out there currently, it would help us a lot when making new
> policy.

What about using wget to create a working copy of the wiki contents,
then recursive grep through it?

Cheers,
 Steffen

-- 
Steffen Grunewald * * * Merlin cluster admin (http://pandora.aei.mpg.de)
Albert-Einstein-Institut (MPI Gravitationsphysik, http://www.aei.mpg.de)
       Science Park Golm, Am M?hlenberg 1, 14476 Potsdam, Germany
e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7233,fax:7298}



From hbo at egbok.com  Thu Mar  3 18:45:03 2005
From: hbo at egbok.com (Howard Owen)
Date: Thu, 03 Mar 2005 10:45:03 -0800
Subject: Call for help
In-Reply-To: <1109874017.4902.56.camel@localhost.localdomain>
References: <1109874017.4902.56.camel@localhost.localdomain>
Message-ID: <1109875503.9337.58.camel@Quirk.egbok.com>

What form would you like the results in?

URL/line offset OK?

On Thu, 2005-03-03 at 10:20 -0800, Jesse Keating wrote:
> Coming very soon, we'll be moving our bugs into Red Hat's bugzilla
> system and living there.  There are many aspects to this move, including
> migration of existing bugs, creating new accounts, re-assigning bugs to
> proper components (now that we'll have them), and also rewriting all our
> policies and guidelines.
> 
> I'm calling for a volunteer to parse through our wiki system and
> website, and report back all the places we reference the Fedora.us
> bugzilla system, and reference bug filing policy in general.  All of
> these pages will have to be updated.  We don't have the new policy
> written or decided just yet, this depends on some aspects and
> limitations of Red Hat's bugzilla system.  However if we have a list of
> whats out there currently, it would help us a lot when making new
> policy.
> 
> Can anybody step up to the challenge?
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
-- 
Howard Owen                      "Even if you are on the right
EGBOK Consultants                 track, you'll get run over if you
hbo at egbok.com    +1-650-218-2216  just sit there." - Will Rogers



From rostetter at mail.utexas.edu  Thu Mar  3 19:28:34 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Thu,  3 Mar 2005 13:28:34 -0600
Subject: [FLSA-2005:2336] Updated kernel packages fix security issues
In-Reply-To: <1109812427.10353.7.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
Message-ID: <1109878114.b723db0f5a5cd@mail.ph.utexas.edu>

Quoting Jim Popovitch <jimpop at yahoo.com>:

> Some of my comments were probably overly harsh.  In an effort get
> something positive out of this discussion, let me continue with why it
> is difficult for me to contribute more.

I don't think it is that difficult to contribute more.  You just need
to find the right place and way to pariticipate.
 
> Let's take "mc" as an issue.

Okay, but that is just once case, and shouldn't stop you from trying to
help in other areas (web site, wiki, overview rewrite, answering questions
on the mailing list, etc).

> there are now some pkgs to d/l and test.  What to test?  Where is the
> details on what should be tested... go read CAN reports.   OK, now I

What kind of testing you do is up to you.  The basic testing is to see
if it installs and runs okay for you.

> think I know what was broke, where do I go to determine what was fixed
> so that I know what to test?   Oh well, I give up and just test the
> stuff that I use in mc.

That is sufficient.

>  Great, all works (afaik), sha1sum and post a
> VERIFY.  More days pass, more deep level comments about more mc issues
> needing resolution.  The result: all the time I spent was a waste.

No, it isn't.  You have at least verified that you didn't find any problems.
More importantly, had you found and reported problems, that would have been
of tremendous help.

But, you don't need to test pre-test RPMS.  You can wait for test RPMS.
Or you can not do testing at all, and help in other ways.
 
> The FL process is painful, difficult, and makes people question whether
> or not they even want to be involved.

That statement may be true if you go deep into the layer of patch/package
creation.  But if so, then don't go that deep into it.  We need plenty
of help outside of that area, which you may be better suited to help with.

> -Jim P.

-- 
Eric Rostetter



From jkeating at j2solutions.net  Thu Mar  3 19:43:35 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 03 Mar 2005 11:43:35 -0800
Subject: Call for help
In-Reply-To: <1109875503.9337.58.camel@Quirk.egbok.com>
References: <1109874017.4902.56.camel@localhost.localdomain>
	<1109875503.9337.58.camel@Quirk.egbok.com>
Message-ID: <1109879015.12887.0.camel@jkeating2.hq.pogolinux.com>

On Thu, 2005-03-03 at 10:45 -0800, Howard Owen wrote:
> What form would you like the results in?
> 
> URL/line offset OK?

Sure, one url per line.  Just something so that the community at large
can look at it, and once I get the final pros/cons of the RH bugzilla
system we can make logical decisions about how the new processes will
work.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jkeating at j2solutions.net  Thu Mar  3 19:43:56 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 03 Mar 2005 11:43:56 -0800
Subject: Call for help
In-Reply-To: <20050303182825.GV14494@debian-server.aei.mpg.de>
References: <1109874017.4902.56.camel@localhost.localdomain>
	<20050303182825.GV14494@debian-server.aei.mpg.de>
Message-ID: <1109879036.12887.2.camel@jkeating2.hq.pogolinux.com>

On Thu, 2005-03-03 at 19:28 +0100, Steffen Grunewald wrote:
> What about using wget to create a working copy of the wiki contents,
> then recursive grep through it?

However you want to accumulate a list is fine with me (:

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From guallar at easternrad.com  Thu Mar  3 19:53:01 2005
From: guallar at easternrad.com (Josep L. Guallar-Esteve)
Date: Thu, 3 Mar 2005 14:53:01 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109872770.4902.50.camel@localhost.localdomain>
References: <421E9E0E.1030000@videotron.ca> <1109872461.11173.52.camel@blue>
	<1109872770.4902.50.camel@localhost.localdomain>
Message-ID: <200503031453.05137.guallar@easternrad.com>

On Thursday 03 March 2005 12:59, Jesse Keating wrote:
> On Thu, 2005-03-03 at 12:54 -0500, Jim Popovitch wrote:
> > But FL does need to have the same *quality*. ?

> No it doesn't. ?FL can't have the same quality of RHEL w/out another Red
> Hat backing it, and last time I checked, cloning isn't quite possible
> yet. ?I'm sorry, but thats just the way it is. ?This is a COMMUNITY
> project and you're going to get COMMUNITY quality.

+1

Fedora Legacy Project provides legacy support, "the COMMUNITY WAY" to a fastly 
evolving Red Hat project aimed as a hacker's Linux distribution.

Fedora is not RHEL.

> > Quality doesn't come
> > easily, and it's not something that should be taken lightly.

> I'm not taking it lightly at all. ?I'm trying to do the best we can,
> realistically.

Fedora Legacy is doing the best job that a limited commmunity like this can 
handle.

Beliving or expecting anything else is unrealisticaly wrong.


Regards,
Josep
-- 
Josep L. Guallar-Esteve		Eastern Radiologists, Inc.
Systems and PACS Administration  http://www.easternrad.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/89901b4b/attachment.sig>

From jimpop at yahoo.com  Thu Mar  3 20:04:31 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 15:04:31 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <200503031453.05137.guallar@easternrad.com>
References: <421E9E0E.1030000@videotron.ca> <1109872461.11173.52.camel@blue>
	<1109872770.4902.50.camel@localhost.localdomain>
	<200503031453.05137.guallar@easternrad.com>
Message-ID: <1109880271.13515.1.camel@blue>

On Thu, 2005-03-03 at 14:53 -0500, Josep L. Guallar-Esteve wrote:
> Fedora Legacy is doing the best job that a limited commmunity like this can 
> handle.
> 
> Beliving or expecting anything else is unrealisticaly wrong.

Put it on the website.  Make it a public statement, give it the teeth
you are giving it in this email rather than leaving it to remain buried
in the archives.

-Jim P.


 



From goisman at physics.arizona.edu  Thu Mar  3 04:23:53 2005
From: goisman at physics.arizona.edu (Philip Goisman)
Date: Wed, 2 Mar 2005 21:23:53 -0700
Subject: FC1 legacy for x86_64
Message-ID: <200503030423.j234NrVO010675@bohr.physics.arizona.edu>

Yes you were very helpful.  Thank you very much for the response.

Regards,

	Philip

	From jkeating at j2solutions.net  Wed Mar  2 17:17:54 2005
	Subject: Re: FC1 legacy for x86_64
	From: Jesse Keating <jkeating at j2solutions.net>
	To: fedora-legacy-list at redhat.com
	Cc: goisman at physics.arizona.edu
	Organization: j2Solutions

	This is a multi-part message in MIME format...

	------------=_1109809044-1634-8
	Content-Type: text/plain; charset=iso-8859-1
	Content-Transfer-Encoding: 7bit
	Content-Disposition: inline

	On Wed, 2005-03-02 at 17:06 -0700, Philip Goisman wrote:
	> Hi,
	> 
	>         Correct me if I'm wrong, but I don't see legacy supporting
	> FC1 x86_64 systems.  If I'm wrong please direct me to where this
	> is documented.  I presently use http://fedoralegacy.org/docs/yum-
	> fc1.php
	> for my FC1 386/586/686 systems.
	> 
	>         My apologies in advance if it's the same procedure except
	> for building gpg and yum from source on x86_64 systems.
	> 
	> 

	At this time we don't support x86_64.  I'm working on getting another
	build box and a build system that will work for x86_64.  Theoretically,
	the Fedora Extras build software will come online rather soon, and I can
	re-deploy our current build box so that it could handle both 32bit and
	64bit package building.  Race condition, which will be done first?  (:

	-- 
	Jesse Keating RHCE      (geek.j2solutions.net)
	Fedora Legacy Team      (www.fedoralegacy.org)
	GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
	 
	Was I helpful?  Let others know:
	 http://svcs.affero.net/rm.php?r=jkeating


	------------=_1109809044-1634-8--



From beartooth at adelphia.net  Thu Mar  3 19:39:23 2005
From: beartooth at adelphia.net (beartooth)
Date: Thu, 03 Mar 2005 14:39:23 -0500
Subject: Error: ... correct GPG keys installed?
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109874371.11173.68.camel@blue>
Message-ID: <pan.2005.03.03.19.39.20.229629@adelphia.net>

On Thu, 03 Mar 2005 13:26:10 -0500, Jim Popovitch wrote:

> 
> Do this:
>    gpg --list-keys

That gave me this, surprisingly, on three machines : 
                            =====
[root at localhost root]# gpg --list-keys
gpg: /root/.gnupg: directory created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/pubring.gpg' created
[root at localhost root]#
                            =====


> If you don't see 2 keys (Fedora Legacy and Red Hat, Inc) then do this:
> 
>    gpg --import /usr/share/doc/yum-1.0.3/RPM-GPG-KEY
>    gpg --import /usr/share/doc/yum-1.0.3/Fedora-Legacy-GPG-KEY

On the first and main machine, one where I do get the GPG error, that gave:
                           =====
[root at localhost root]# gpg --import /usr/share/doc/yum-1.0.3/RPM-GPG-KEY
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: can't open `/usr/share/doc/yum-1.0.3/RPM-GPG-KEY': No such file or directory
gpg: Total number processed: 0
[root at localhost root]# gpg --import /usr/share/doc/yum-1.0.3/Fedora-Legacy-GPG-KEY
gpg: can't open `/usr/share/doc/yum-1.0.3/Fedora-Legacy-GPG-KEY': No such file or directory
gpg: Total number processed: 0
[root at localhost root]#
                          =====

> If that doesn't work
> 
>    rm -rf /root/.gnupg
>    (repeat above)

Well, I hope I understood the correct "above" to repeat. I did : 
                            =====
[root at localhost root]# rm -rf /root/.gnupg
[root at localhost root]# gpg --list-keys
gpg: /root/.gnupg: directory created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/pubring.gpg' created
[root at localhost root]# gpg --import /usr/share/doc/yum-1.0.3/RPM-GPG-KEY
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: can't open `/usr/share/doc/yum-1.0.3/RPM-GPG-KEY': No such file or directory
gpg: Total number processed: 0
[root at localhost root]# gpg --import /usr/share/doc/yum-1.0.3/Fedora-Legacy-GPG-KEY
gpg: can't open `/usr/share/doc/yum-1.0.3/Fedora-Legacy-GPG-KEY': No such file or directory
gpg: Total number processed: 0
[root at localhost root]#
                          =====
Trying again, I still get : 
                          =====
[....]
Is this ok [y/N]: y
warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 8df56d05
Error: Could not find the GPG Key necessary to validate pkg /var/cache/yum/fedora-stable/packages/perl-DateManip-5.42-0.fdr.2.a.1.noarch.rpm
Error: You may want to run yum clean or remove the file:
 /var/cache/yum/fedora-stable/packages/perl-DateManip-5.42-0.fdr.2.a.1.noarch.rpm
Error: You may also check that you have the correct GPG keys installed
[root at localhost root]#
                         =====

So did I misinterpret what to do over again? Or what?
-- 
Beartooth Implacable, Linux Evangelist & Gadfly
neo-redneck, curmudgeonly codger with FC1 & YDL 4.0
Pine 4.61, Pan 0.14.2; Privoxy 3.0.1; Opera 7.54, Firefox 1.0
Bear in mind that I have little idea what I am talking about.




From beartooth at adelphia.net  Thu Mar  3 19:43:47 2005
From: beartooth at adelphia.net (beartooth)
Date: Thu, 03 Mar 2005 14:43:47 -0500
Subject: Error: ... correct GPG keys installed?
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109873341.9846.447.camel@serendipity.dogma.lan>
Message-ID: <pan.2005.03.03.19.43.46.910288@adelphia.net>

On Thu, 03 Mar 2005 19:09:01 +0100, Alexander Dalloz wrote:

> Please tell us:
> 
> a) which GPG is claimed to be missing
> b) for which packages from where (repository)
> c) output of following single line command:
> for key in $(rpm -qa | grep pubkey); do rpm -qi ${key} | head -10; done

I'm sorry : I don't know how to get the answers to a) nor b) -- but I did
do c) immediately after the things Jim Popovich had suggested -- and got
this :
                         =====
[root at localhost root]# for key in $(rpm -qa | grep pubkey); do rpm -qi
${key} | head -10; done Name        : gpg-pubkey Relocations: (not
relocateable) Version     : 4f2a6fd2
     Vendor: (none) Release     : 3f9d9d3b                      Build
Date: Thu 13 Jan 2005 07:30:52 PM EST Install Date: Thu 13 Jan 2005
07:30:52 PM EST      Build Host: localhost Group       : Public Keys
            Source RPM: (none) Size        : 0
   License: pubkey Signature   : (none)
Summary     : gpg(Fedora Project <fedora at redhat.com>) Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Name        : gpg-pubkey                   Relocations: (not relocateable)
Version     : db42a60e                          Vendor: (none) Release
: 37ea5438                      Build Date: Thu 13 Jan 2005 07:30:51 PM
EST Install Date: Thu 13 Jan 2005 07:30:51 PM EST      Build Host:
localhost Group       : Public Keys                   Source RPM: (none)
Size        : 0                                License: pubkey Signature
: (none)
Summary     : gpg(Red Hat, Inc <security at redhat.com>) Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
[root at localhost root]#
                                =====

-- 
Beartooth Implacable, Linux Evangelist & Gadfly
neo-redneck, curmudgeonly codger with FC1 & YDL 4.0
Pine 4.61, Pan 0.14.2; Privoxy 3.0.1; Opera 7.54, Firefox 1.0
Bear in mind that I have little idea what I am talking about.




From ad+lists at uni-x.org  Thu Mar  3 20:10:36 2005
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Thu, 03 Mar 2005 21:10:36 +0100
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <1109874371.11173.68.camel@blue>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109874371.11173.68.camel@blue>
Message-ID: <1109880636.9846.455.camel@serendipity.dogma.lan>

Am Do, den 03.03.2005 schrieb Jim Popovitch um 19:26:

> Do this:
>    gpg --list-keys
> 
> If you don't see 2 keys (Fedora Legacy and Red Hat, Inc) then do this:
> 
>    gpg --import /usr/share/doc/yum-1.0.3/RPM-GPG-KEY
>    gpg --import /usr/share/doc/yum-1.0.3/Fedora-Legacy-GPG-KEY
> 
> If that doesn't work
> 
>    rm -rf /root/.gnupg
>    (repeat above)
> 
> hth,
> 
> -Jim P.

Sorry, this is nonsense. the GPG keyring has nothing to do with the GPG
keys in the RPM DB.

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.14_FC2smp 
Serendipity 21:09:46 up 10 days, 8:18, load average: 2.75, 1.04, 0.70 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/1232ce56/attachment.sig>

From mattdm at mattdm.org  Thu Mar  3 20:12:36 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 3 Mar 2005 15:12:36 -0500
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <1109874371.11173.68.camel@blue>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109874371.11173.68.camel@blue>
Message-ID: <20050303201236.GA16853@jadzia.bu.edu>

On Thu, Mar 03, 2005 at 01:26:10PM -0500, Jim Popovitch wrote:
>    gpg --list-keys

While this is generally right for gpg, Alexander Dalloz is correct in that
it doesn't apply to rpm package signatures, which is what yum is checking.
Instead, you need to have the right gpg key in your RPM database -- check
with `rpm -q gpg-pubkey`, and import with `rpm --import
Fedora-Legacy-GPG-KEY`.

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From jimpop at yahoo.com  Thu Mar  3 20:12:13 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 15:12:13 -0500
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <1109880636.9846.455.camel@serendipity.dogma.lan>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109874371.11173.68.camel@blue>
	<1109880636.9846.455.camel@serendipity.dogma.lan>
Message-ID: <1109880733.13515.4.camel@blue>

On Thu, 2005-03-03 at 21:10 +0100, Alexander Dalloz wrote:
> Am Do, den 03.03.2005 schrieb Jim Popovitch um 19:26:
> 
> > Do this:
> >    gpg --list-keys
> > 
> > If you don't see 2 keys (Fedora Legacy and Red Hat, Inc) then do this:
> > 
> >    gpg --import /usr/share/doc/yum-1.0.3/RPM-GPG-KEY
> >    gpg --import /usr/share/doc/yum-1.0.3/Fedora-Legacy-GPG-KEY
> > 
> > If that doesn't work
> > 
> >    rm -rf /root/.gnupg
> >    (repeat above)
> > 
> > hth,
> > 
> > -Jim P.
> 
> Sorry, this is nonsense. the GPG keyring has nothing to do with the GPG
> keys in the RPM DB.

LOL!.

-Jim P.



From ad+lists at uni-x.org  Thu Mar  3 20:13:53 2005
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Thu, 03 Mar 2005 21:13:53 +0100
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <pan.2005.03.03.19.43.46.910288@adelphia.net>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109873341.9846.447.camel@serendipity.dogma.lan>
	<pan.2005.03.03.19.43.46.910288@adelphia.net>
Message-ID: <1109880833.9846.457.camel@serendipity.dogma.lan>

Am Do, den 03.03.2005 schrieb beartooth um 20:43:

> > Please tell us:
> > 
> > a) which GPG is claimed to be missing
> > b) for which packages from where (repository)
> > c) output of following single line command:
> > for key in $(rpm -qa | grep pubkey); do rpm -qi ${key} | head -10; done
> 
> I'm sorry : I don't know how to get the answers to a) nor b) -- but I did
> do c) immediately after the things Jim Popovich had suggested -- and got
> this :

 [ snipped ]

rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.14_FC2smp 
Serendipity 21:13:12 up 10 days, 8:21, load average: 0.71, 0.81, 0.66 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/096b8d5a/attachment.sig>

From jimpop at yahoo.com  Thu Mar  3 20:14:40 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 15:14:40 -0500
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <pan.2005.03.03.19.39.20.229629@adelphia.net>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109874371.11173.68.camel@blue>
	<pan.2005.03.03.19.39.20.229629@adelphia.net>
Message-ID: <1109880880.13515.8.camel@blue>

On Thu, 2005-03-03 at 14:39 -0500, beartooth wrote:
> On Thu, 03 Mar 2005 13:26:10 -0500, Jim Popovitch wrote:
> 
> > 
> > Do this:
> >    gpg --list-keys
> 
> That gave me this, surprisingly, on three machines : 
>                             =====
> [root at localhost root]# gpg --list-keys
> gpg: /root/.gnupg: directory created
> gpg: new configuration file `/root/.gnupg/gpg.conf' created
> gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
> gpg: keyring `/root/.gnupg/pubring.gpg' created
> [root at localhost root]#

OK, 

That out suggests that you have zero keys installed.  

You will need to install the two signing keys, on RH73 they are
installed like this:
  
   gpg --import /usr/share/doc/yum-1.0.3/RPM-GPG-KEY
   gpg --import /usr/share/doc/yum-1.0.3/Fedora-Legacy-GPG-KEY
 
On FC systems you will need to use "rpm --import" rather than gpg, and
the key locations will vary somewhat.

-Jim 



From jimpop at yahoo.com  Thu Mar  3 20:17:04 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 15:17:04 -0500
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <20050303201236.GA16853@jadzia.bu.edu>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109874371.11173.68.camel@blue> <20050303201236.GA16853@jadzia.bu.edu>
Message-ID: <1109881024.13515.11.camel@blue>

On Thu, 2005-03-03 at 15:12 -0500, Matthew Miller wrote:
> On Thu, Mar 03, 2005 at 01:26:10PM -0500, Jim Popovitch wrote:
> >    gpg --list-keys
> 
> While this is generally right for gpg, Alexander Dalloz is correct in that
> it doesn't apply to rpm package signatures, which is what yum is checking.
> Instead, you need to have the right gpg key in your RPM database -- check
> with `rpm -q gpg-pubkey`, and import with `rpm --import
> Fedora-Legacy-GPG-KEY`.

That advice doesn't apply to versions less than FC1 and RH9 (and perhaps
even RH8).

-Jim P.






From guallar at easternrad.com  Thu Mar  3 20:18:51 2005
From: guallar at easternrad.com (Josep L. Guallar-Esteve)
Date: Thu, 3 Mar 2005 15:18:51 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109880271.13515.1.camel@blue>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
Message-ID: <200503031518.53988.guallar@easternrad.com>

On Thursday 03 March 2005 15:04, Jim Popovitch wrote:
> On Thu, 2005-03-03 at 14:53 -0500, Josep L. Guallar-Esteve wrote:
> > Fedora Legacy is doing the best job that a limited commmunity like this
> > can handle.
> >
> > Beliving or expecting anything else is unrealisticaly wrong.
>
> Put it on the website. ?Make it a public statement, give it the teeth
> you are giving it in this email rather than leaving it to remain buried
> in the archives.
>
> -Jim P.

After reding the Fedora Linux Project website I got the ipression (later 
confirmed when talking with RH engineers) that Fedora Core is not meant to be 
used in "enterprise environment". 

And Fedora Legacy Project was born to provide support to phased-out Red Hat 
Linux distributions and to-be-phased-out Fedora Core distributions, as Fedora 
Core's official support is very short.

Fedora Linux PRoject and Fedora Legacy Project are community-oriented 
projects. Fedora Legacy is totaly community-driven project.

So , IMHO, there's no need to post every 2 sentences a discclaimer saying 
"Warning! F.L.P. is not corporate-grade nor ISO9001! "

In FLP main page it says:


"What is The Fedora Legacy Project?

The Fedora Legacy Project is a community-supported open source project. It is 
not a supported project of Red Hat, Inc. although Red Hat, Inc. does provide 
some support services for it.

The goal of The Fedora Legacy Project is to work with the Linux community to 
provide security and critical bug fix errata packages for select End of Life 
Red Hat Linux and Fedora Core distributions. This will allow for a longer 
effective life for those releases.

To learn more please refer to the About page and the FAQs. "


This is on the top-center part of the page. Impossible to avoid.



Regards,
Josep
-- 
Josep L. Guallar-Esteve		Eastern Radiologists, Inc.
Systems and PACS Administration  http://www.easternrad.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/6ba996a5/attachment.sig>

From jimpop at yahoo.com  Thu Mar  3 20:36:35 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 15:36:35 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <200503031518.53988.guallar@easternrad.com>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
Message-ID: <1109882195.13515.21.camel@blue>

On Thu, 2005-03-03 at 15:18 -0500, Josep L. Guallar-Esteve wrote:
> And Fedora Legacy Project was born to provide support to phased-out Red Hat 
> Linux distributions and to-be-phased-out Fedora Core distributions, as Fedora 
> Core's official support is very short.

So, why invest time and $$ in RH and/or Fedora if the phase-out process
is not treated as sincerely as the roll-out?

All I'm saying is this:  Put the truth on the website.  If FL isn't
meant to be relied upon, nor if it isn't meant to be used in production
systems, nor if it isn't suppose to be quality support for EOL'ed RH
systems... just put the truth on the website so that visitors have
correct data. 

It seems to me that this following paragraph from the website should be
removed:

  "The goal of The Fedora Legacy Project is to work with the Linux
   community to provide security and critical bug fix errata packages
   for select End of Life Red Hat Linux and Fedora Core distributions.
   This will allow for a longer effective life for those releases."

After all, the above goes counter to a lot of the comments expressed
here today.  Notably the ones about "test it yourself" and "expecting
anything else is unrealisticaly wrong."

-Jim P.



From pekkas at netcore.fi  Thu Mar  3 20:50:18 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Thu, 3 Mar 2005 22:50:18 +0200 (EET)
Subject: how to get started with helping the project [...]
In-Reply-To: <1109882195.13515.21.camel@blue>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
Message-ID: <Pine.LNX.4.61.0503032246580.10083@netcore.fi>

On Thu, 3 Mar 2005, Jim Popovitch wrote:
> All I'm saying is this:  Put the truth on the website.  If FL isn't
> meant to be relied upon, nor if it isn't meant to be used in production
> systems, nor if it isn't suppose to be quality support for EOL'ed RH
> systems... just put the truth on the website so that visitors have
> correct data.

It's meant to be _community support_.

> It seems to me that this following paragraph from the website should be
> removed:
>
>  "The goal of The Fedora Legacy Project is to work with the Linux
>   community to provide security and critical bug fix errata packages
>   for select End of Life Red Hat Linux and Fedora Core distributions.
>   This will allow for a longer effective life for those releases."
>
> After all, the above goes counter to a lot of the comments expressed
> here today.  Notably the ones about "test it yourself" and "expecting
> anything else is unrealisticaly wrong."

This is still valid, unless you assume that the updates for EOL 
distributions are useless unless they are very rigorously tested under 
industry-grade circumstances.

A lot of people obviously disagree with that notion, so the text is 
correct.

If you have constructive wording suggestion without the abovementioned 
assumption, I'm sure we'd like to hear it..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From brian.t.brunner at gai-tronics.com  Thu Mar  3 20:54:10 2005
From: brian.t.brunner at gai-tronics.com (Brian T. Brunner)
Date: Thu, 03 Mar 2005 12:54:10 -0800
Subject: how to get started with helping the project [...]
Message-ID: <s2270904.084@CRPSPKWANW02-IA.hubbell.com>



Brian Brunner
brian.t.brunner at gai-tronics.com
(610)796-5838

>>> jimpop at yahoo.com 03/03/05 01:04PM >>>
On Thu, 2005-03-03 at 12:46 -0500, Marc Deslauriers wrote:

> This is a community effort, 

> No it's not.  It's what 4 people, maybe 5 that really do stuff?
> Shouldn't there be more?  

So... you're going to make it 5 or 6, or leave it as it is?

....or are you going to take time from the 5 or 6 explaining to you why it isn't 50 or 60?

.... You should have been here when we debated whether to keep RH8.

.... and why we decided to drop it.

*******************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept
for the presence of computer viruses.

www.hubbell.com - Hubbell Incorporated



From ad+lists at uni-x.org  Thu Mar  3 20:59:23 2005
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Thu, 03 Mar 2005 21:59:23 +0100
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <1109880733.13515.4.camel@blue>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109874371.11173.68.camel@blue>
	<1109880636.9846.455.camel@serendipity.dogma.lan>
	<1109880733.13515.4.camel@blue>
Message-ID: <1109883563.9846.469.camel@serendipity.dogma.lan>

Am Do, den 03.03.2005 schrieb Jim Popovitch um 21:12:

> > Sorry, this is nonsense. the GPG keyring has nothing to do with the GPG
> > keys in the RPM DB.
> 
> LOL!.
> 
> -Jim P.

Sorry Jim if my words sounded a bit harsh. I really apologise.
But if you look at "Beartooth's" signature you see that he is running
Fedora Core 1. And I remember him from the Fedora User list as being and
not very experienced user. So if you confuse him directing into the gpg
binary usage, that does not help him. He simply does not know anything
about the GPG signing, I fear (reading his initial posting and reply).
I think he is a Fedora Core 1 user and found out lately that security
updates are coming from the Fedora Legacy Project for his release. And
as these packages have a different GPG sign than those from Red Hat, he
now does not know how to install the update packages from FLP. He may
correct me if I am wrong. If he did read

http://www.fedoralegacy.org/about/security.php

at least he didn't understand it.

Again sorry, Jim. I didn't count with those really old RH 7.3
installations some people still seem to run. This was clearly my fault.
But your advise to "Beartooth" didn't deal in any way with the more
modern FC1. Peace? :)

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.14_FC2smp 
Serendipity 21:48:47 up 10 days, 8:57, load average: 0.44, 0.69, 0.77 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/8b40a518/attachment.sig>

From guallar at easternrad.com  Thu Mar  3 21:00:43 2005
From: guallar at easternrad.com (Josep L. Guallar-Esteve)
Date: Thu, 3 Mar 2005 16:00:43 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109882195.13515.21.camel@blue>
References: <421E9E0E.1030000@videotron.ca>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
Message-ID: <200503031600.47632.guallar@easternrad.com>

On Thursday 03 March 2005 15:36, Jim Popovitch wrote:
> So, why invest time and $$ in RH and/or Fedora if the phase-out process
> is not treated as sincerely as the roll-out?

This is up to everybody joining any community project. Everyone, in their own 
way, will invest as much tima and as much money as they see fit.

And sincerity has nothing to do with this: everything is up-front to 
everybody. Everybody has access to the same packages, everybody can join the 
effort and help the community project. And it is spelled out clearly: 
community effort.

As far as I know, I am not paying tons of money, in a yearly contract, to get 
Fedora Legacy updates.

For example, whenever I have the need for a need-to-be-supported system, or 
cannot-go-wrong system or my-bottom-will-burn-if-this-goes-down kind of 
project, I get a support contract with Red Hat and I install RHEL.

For internal stuff, non-critical, testlab and such, the RHL 7.x down there get 
Fedora Legacy updates.

> After all, the above goes counter to a lot of the comments expressed
> here today. ?Notably the ones about "test it yourself" and "expecting
> anything else is unrealisticaly wrong."
>
> -Jim P.

I think not.

This ("test it yourself") is exactly  "the Community way" of doing things. 

Do you need something? ("Do you have an itch?") 

So you do it yourself ("you scratch your own itch"). In order to successfuly 
complete your task, you ask for help to the community . And then, you inform 
the community of your task's results, making your work available to everyone.



Regards,
Josep
-- 
Josep L. Guallar-Esteve		Eastern Radiologists, Inc.
Systems and PACS Administration  http://www.easternrad.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050303/2e19c781/attachment.sig>

From dr at cluenet.de  Thu Mar  3 21:06:30 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Thu, 3 Mar 2005 22:06:30 +0100
Subject: how to get started with helping the project [...]
In-Reply-To: <Pine.LNX.4.61.0503032246580.10083@netcore.fi>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
	<Pine.LNX.4.61.0503032246580.10083@netcore.fi>
Message-ID: <20050303210630.GA4513@srv01.cluenet.de>

On Thu, Mar 03, 2005 at 10:50:18PM +0200, Pekka Savola wrote:
> This is still valid, unless you assume that the updates for EOL 
> distributions are useless unless they are very rigorously tested under 
> industry-grade circumstances.

The problem is that people who take security serious can't wait weeks
and months for security fixes to arrive from FL. And as that's (security
fixes) all FL provides...

For me, FL is only of value if I can save time by just installing FL
RPMs instead of rolling my own security updates. But at least remotely
exploitable vulnerabilities require *immediate* fix so people can't wait
weeks and months for FL to get into gear. So one has to backport or
install newer, fixed versions manually. So no time saved at all.

I'm surely NOT picking on the FL project. It's all free (as in "beer")
after all, and the intentions are very noble. But it's IMHO a fact that
current procedures (and probably lack of community manpower) lead to
unacceptable delays which renders the whole project's point somewhat
moot.

Really, don't get me wrong, and thanks to all contributors for their
commitment.

Just my 0.02 EUR.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From lists at securityspace.com  Thu Mar  3 21:07:17 2005
From: lists at securityspace.com (Thomas Reinke)
Date: Thu, 03 Mar 2005 16:07:17 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109882195.13515.21.camel@blue>
References: <421E9E0E.1030000@videotron.ca>	<200503031453.05137.guallar@easternrad.com>	<1109880271.13515.1.camel@blue>	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
Message-ID: <42277C85.506@securityspace.com>

Jim Popovitch wrote:

> All I'm saying is this:  Put the truth on the website.  If FL isn't
> meant to be relied upon, nor if it isn't meant to be used in production
> systems, nor if it isn't suppose to be quality support for EOL'ed RH
> systems... just put the truth on the website so that visitors have
> correct data. 

It seems you're not asking for the truth. You're asking for your
requirements to be reflected in the statements on the web site and
the handling of the project as a whole.  But your requirements are
not the same, it seems, as others.  FL CAN be relied upon, IS used
in production systems, and has adequate quality of support (for us).
But then, as you see, our requirements as a tech savvy shop are a bit
different from yours. As a lurker ONLY, I see nothing misleading or
misrepresentative of the legacy project or the statements.

1) There is a community of people (small, but there none-the-less)
    providing work to extend the life of selected RH/FC releases

2) They provide this work for FREE.

3) They make no guarantees about the quality. But hell, nor does
    FC.  For those of us that choose to use FC and extend its
    usefulness with FC Legacy, I see nothing misrepresented here.

4) They provide this work for FREE. For FREE!!!! If you don't like
    it, either get involved, or use another distribution.
    There's nothing wrong with providing some criticism where due,
    but there's a fine line to toe when criticizing the quality
    of something that comes for free and for which (it would appear)
    the largest effort that has been expended is in this email
    thread.

 From my perspective, Kudos to the legacy team for tackling a hell
of a difficult job with very limited resources and for actually
making somewhat a go of it.

Thomas



From matt.followers at gmail.com  Thu Mar  3 21:11:10 2005
From: matt.followers at gmail.com (Matthew Nuzum)
Date: Thu, 03 Mar 2005 16:11:10 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <200503031518.53988.guallar@easternrad.com>
References: <421E9E0E.1030000@videotron.ca>	<200503031453.05137.guallar@easternrad.com>	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
Message-ID: <42277D6E.30908@gmail.com>

Josep L. Guallar-Esteve wrote:

>On Thursday 03 March 2005 15:04, Jim Popovitch wrote:
>  
>
>>On Thu, 2005-03-03 at 14:53 -0500, Josep L. Guallar-Esteve wrote:
>>    
>>
>>>Fedora Legacy is doing the best job that a limited commmunity like this
>>>can handle.
>>>
>>>Beliving or expecting anything else is unrealisticaly wrong.
>>>      
>>>
>>Put it on the website.  Make it a public statement, give it the teeth
>>you are giving it in this email rather than leaving it to remain buried
>>in the archives.
>>
>>-Jim P.
>>    
>>
>
>So , IMHO, there's no need to post every 2 sentences a discclaimer saying 
>"Warning! F.L.P. is not corporate-grade nor ISO9001! "
>  
>
There is still a great mis-understanding among the Linux community at 
large on this point. To many, FC == "RedHat Linux" and they are in 
denial that FC is bleeding edge, unsupported and will require frequent 
upgrades/reboots/bug fixes.

The full weight of what it means when an FC project is migrated to FL is 
lost to most.

I really wish people understood that:

    Fedora Core is a community based linux distribution that will be
    supported by the FC community for aproximately 9 - 10 months, at
    which point limited support for major security updates will be
    availble for another 9 - 10 months by the FL community. Only use FC
    if you plan on upgrading your system every 6 months and only count
    on FL to provide the absolute essential updates for a limited time
    after the FC release has been retired. Total support for a FC
    distribution will not exceed 18 months in most cases.

I really don't think it hurts to make it clear. People always get upset 
when their expectations have been let-down. Helping people get their 
expectations in line with reality can avoid a lot of hard feelings, IMHO.

It is my personal opinion, and I've been flamed for this before, that FL 
is only a transitional project. I think that when people realize FC is 
unsupported and that they should upgrade whenever a new version comes 
out, demand for FL will decrease. If a person/organization needs a 
supported distro that can be put in place for 1 - 5 years, FC is NOT the 
right choice. Anything that the FL community can do to make this point 
clear will be beneficial in the long term. (and will ensure that FL 
ceases to exist in another year or two)

FC == `uptime` < 270 days
FC + FL == `uptime` < 500 days
RHEL/SLES == `uptime` > 500 days

-- 
Matthew Nuzum <matt at followers.net>
www.followers.net - Makers of "Elite Content Management System"
View samples of Elite CMS in action by visiting
http://www.followers.net/portfolio/



From jkeating at j2solutions.net  Thu Mar  3 21:14:26 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 03 Mar 2005 13:14:26 -0800
Subject: how to get started with helping the project [...]
In-Reply-To: <20050303210630.GA4513@srv01.cluenet.de>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
	<Pine.LNX.4.61.0503032246580.10083@netcore.fi>
	<20050303210630.GA4513@srv01.cluenet.de>
Message-ID: <1109884466.12887.11.camel@jkeating2.hq.pogolinux.com>

On Thu, 2005-03-03 at 22:06 +0100, Daniel Roesen wrote:
> The problem is that people who take security serious can't wait weeks
> and months for security fixes to arrive from FL. And as that's
> (security
> fixes) all FL provides...

This is very true.  It continues to be my main goal to get packages out
quicker.  One can say the same about distros like Red Hat and Debian, in
that the time between a vuln being known and packages coming out may be
too long for the really sensitive systems.  Although, these distros
communicate about vulns using VendorSec in a non-public way, and are
able to coordinate the announcement of and therefor the release of
packages.  Fedora Legacy is part of VendorSec now, however to really act
on any information I get from there, I would need to close community
access to the bug and communicate privately with a very very select few
about the issue.  I'm torn on this.  It would allow for potentially
faster and more coordinated packages, but the community would have a lot
less chance to do the QA and testing.  It is a very hard thing to do.
What may happen is that we'll have testing packages ready at coordinated
announce time, for the community to QA so that we can release shortly
thereafter.  Is anybody opposed to this strategy?  It will still mean
private bugs in bugzilla until ready for announcement.

> For me, FL is only of value if I can save time by just installing FL
> RPMs instead of rolling my own security updates. But at least remotely
> exploitable vulnerabilities require *immediate* fix so people can't
> wait
> weeks and months for FL to get into gear. So one has to backport or
> install newer, fixed versions manually. So no time saved at all.

Right.  THere are those that don't rely on the vendor at all for
security fixes, they do it themselves using source on the critical
systems.  There is no way to compete with the speed this can have.

> I'm surely NOT picking on the FL project. It's all free (as in "beer")
> after all, and the intentions are very noble. But it's IMHO a fact
> that
> current procedures (and probably lack of community manpower) lead to
> unacceptable delays which renders the whole project's point somewhat
> moot.

For a lot of systems yes.  For other less sensitive systems we still
provide a good service.  Especially for those who lack the manpower to
take care of these things on their own.

> Really, don't get me wrong, and thanks to all contributors for their
> commitment.
> 
> Just my 0.02 EUR.

I do appreciate your feedback!

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From mattdm at mattdm.org  Thu Mar  3 21:17:22 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 3 Mar 2005 16:17:22 -0500
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <1109881024.13515.11.camel@blue>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109874371.11173.68.camel@blue>
	<20050303201236.GA16853@jadzia.bu.edu>
	<1109881024.13515.11.camel@blue>
Message-ID: <20050303211722.GA19102@jadzia.bu.edu>

On Thu, Mar 03, 2005 at 03:17:04PM -0500, Jim Popovitch wrote:
> That advice doesn't apply to versions less than FC1 and RH9 (and perhaps
> even RH8).

Ah, good point. How quickly I forget the bad old days. :)

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From jimpop at yahoo.com  Thu Mar  3 21:30:18 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 03 Mar 2005 16:30:18 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <s2270904.084@CRPSPKWANW02-IA.hubbell.com>
References: <s2270904.084@CRPSPKWANW02-IA.hubbell.com>
Message-ID: <1109885418.13515.29.camel@blue>

On Thu, 2005-03-03 at 12:54 -0800, Brian T. Brunner wrote:
>
> .... You should have been here when we debated whether to keep RH8.

I was.

> .... and why we decided to drop it.

And I agreed (and still do) with the decision.  ;-)

-Jim P.



From marcus.lauer at nyu.edu  Thu Mar  3 23:39:09 2005
From: marcus.lauer at nyu.edu (Marcus Lauer)
Date: 03 Mar 2005 18:39:09 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <42277C85.506@securityspace.com>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>  <42277C85.506@securityspace.com>
Message-ID: <1109893149.5963.69.camel@bizzaro.psych.nyu.edu>

On Thu, 2005-03-03 at 16:07, Thomas Reinke wrote:
> Jim Popovitch wrote:
> 
> > All I'm saying is this:  Put the truth on the website.  If FL isn't
> > meant to be relied upon, nor if it isn't meant to be used in production
> > systems, nor if it isn't suppose to be quality support for EOL'ed RH
> > systems... just put the truth on the website so that visitors have
> > correct data. 
> 
> It seems you're not asking for the truth. You're asking for your
> requirements to be reflected in the statements on the web site and
> the handling of the project as a whole.  But your requirements are
> not the same, it seems, as others.  FL CAN be relied upon, IS used
> in production systems, and has adequate quality of support (for us).
> But then, as you see, our requirements as a tech savvy shop are a bit
> different from yours. As a lurker ONLY, I see nothing misleading or
> misrepresentative of the legacy project or the statements.
> 
> 1) There is a community of people (small, but there none-the-less)
>     providing work to extend the life of selected RH/FC releases
> 
> 2) They provide this work for FREE.
> 
> 3) They make no guarantees about the quality. But hell, nor does
>     FC.  For those of us that choose to use FC and extend its
>     usefulness with FC Legacy, I see nothing misrepresented here.
> 
> 4) They provide this work for FREE. For FREE!!!! If you don't like
>     it, either get involved, or use another distribution.
>     There's nothing wrong with providing some criticism where due,
>     but there's a fine line to toe when criticizing the quality
>     of something that comes for free and for which (it would appear)
>     the largest effort that has been expended is in this email
>     thread.
> 
>  From my perspective, Kudos to the legacy team for tackling a hell
> of a difficult job with very limited resources and for actually
> making somewhat a go of it.

        As a lurker myself, I'm more inclined to side with Mr.
Popovitch.  His original criticisms about there not being an e-mail
about the website going down and about there not being an alternate
leader in case something happens to Mr. Keating's ability to communicate
aren't unreasonable.  That doesn't mean that they're right, but just
that they're the sort of thing which should lead to a discussion.  I
mean, what would happen to the project if Mr. Keating just disappeared
one day?  Is there any contingency plan in place at all?

        Here's how this all started.  Apparently Mr. Popovitch had put a
lot of effort into finding out what happened to the website, and after
several e-mails trying to figure out why there was nothing mentioned on
the e-mail list, he finally got frustrated enough to post that "At the
risk of sounding like an absolute ass" e-mail.  It didn't sound to be
like a particularly insulting e-mail, just a frustrated one.  The
replies, especially the out-and-out flame from Mr. Vidal, sounded much
worse to me.  That led to a flamewar which like all flamewars got out of
control, made everyone divisive about every little comment, and so on.

        Again, while I don't agree with Mr. Popovitch's position on
everything, I think that he has made some legitimate criticisms of the
project and I think that they got ignored (this time -- I see that Mr.
Popovitch has been around for a while and has made suggestions which did
get discussed previously).  My guess is that a lot of the people
involved were frustrated or under stress because of things like websites
and build servers going down.  That sort of thing happens.  It's
unfortunate, but there's just no way to prevent people from having bad
days. :)  What really worries me is the way that phrases like "volunteer
project" and "they work for free" are being used.  They're being used to
mean "take it or leave it".  While this is well within the rights of a
volunteer group, it's generally not a good way to operate any sort of
project.  Criticism can be a valuable contribution, and criticism coming
from outside of the core group working on a project can help illustrate
problems which they might miss.

        For example, take Mr. Popovitch's Bugzilla/Midnight Commander
comment.  I'm inclined to agree.  The one time I tried to submit a bug
to Bugzilla, I couldn't figure out how.  Admittedly, I didn't spend a
whole lot of time on it, but I did find the time to figure out that bug
in some detail so that I could report it.  More recently, when I tried
to figure out why nfs-utils was in testing I couldn't find anything on
it.  Every now and then I'm willing to contribute to FL, but I'm having
trouble.  Mr. Popovitch described this aspect of FL as "painful" and
"difficult" (and I notice that the thread was simply dropped after that
post).  I would be more specific in saying that perhaps it should be a
goal of the FL project to put something more detailed than just "Report
your test results in the Bugzilla system." on the wiki so that the
newbies have an easier time of picking it up.  I suspect that this is
the sort of thing that a core group on a project would miss, in this
case because they all know how to use Bugzilla already and think it's
easy.

        Meanwhile, several respondents are saying things like "they're
working for free, so either get involved ('take it' as is) or go use
another distro ('go away')".  Based on my experience, I sympathize with
whomever is _not_ saying that.  Sure the FL team is working for free,
and that's great, but are they really unwilling to listen to people who
say "things could be better, here's how"?  Especially coming from people
who _have_ done at least a little work for FL?  I sure hope not.  One of
the Catch-22s of volunteer projects is that the people who volunteer
already like the project.  They're the people least likely to criticize
its flaws.  So then who will identify flaws in the project?

        Again, when the hard feelings from this flamewar have left
everyone, I hope we can all go back and think about what has been said. 
The FL project is not perfect.  There are criticisms of it to be made,
and I think that some of the ones made this time were legit, or at least
worth discussing.

-- 

Marcus Lauer
Lab Manager for the Curtis Lab
6 Washington Square, Rooms 875 and 876
Psychology Department, NYU
Phone: (212)998-8347
http://psych.nyu.edu/curtislab/



From mic at npgx.com.au  Thu Mar  3 23:48:30 2005
From: mic at npgx.com.au (Michael Mansour)
Date: Fri, 4 Mar 2005 09:48:30 +1000
Subject: how to get started with helping the project [...]
In-Reply-To: <42277D6E.30908@gmail.com>
References: <421E9E0E.1030000@videotron.ca>	<200503031453.05137.guallar@easternrad.com>	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<42277D6E.30908@gmail.com>
Message-ID: <20050303233756.M6366@npgx.com.au>

> >So , IMHO, there's no need to post every 2 sentences a discclaimer saying 
> >"Warning! F.L.P. is not corporate-grade nor ISO9001! "
> >  
> >
> There is still a great mis-understanding among the Linux community 
> at large on this point. To many, FC == "RedHat Linux" and they are 
> in denial that FC is bleeding edge, unsupported and will require 
> frequent upgrades/reboots/bug fixes.
> 
> The full weight of what it means when an FC project is migrated to 
> FL is lost to most.
> 
> I really wish people understood that:
> 
>     Fedora Core is a community based linux distribution that will be
>     supported by the FC community for aproximately 9 - 10 months, at
>     which point limited support for major security updates will be
>     availble for another 9 - 10 months by the FL community. Only use 
> FC    if you plan on upgrading your system every 6 months and only count
>     on FL to provide the absolute essential updates for a limited 
> time    after the FC release has been retired. Total support for a 
> FC    distribution will not exceed 18 months in most cases.
> 
> I really don't think it hurts to make it clear. People always get 
> upset when their expectations have been let-down. Helping people get 
> their expectations in line with reality can avoid a lot of hard 
> feelings, IMHO.
> 
> It is my personal opinion, and I've been flamed for this before, 
> that FL is only a transitional project. I think that when people 
> realize FC is unsupported and that they should upgrade whenever a 
> new version comes out, demand for FL will decrease. If a 
> person/organization needs a supported distro that can be put in 
> place for 1 - 5 years, FC is NOT the right choice. Anything that the 
> FL community can do to make this point clear will be beneficial in 
> the long term. (and will ensure that FL ceases to exist in another 
> year or two)

I would tend to agree with you there Matthew. When I started with installing 
FC1, then FC2, then FC3 releases on servers (upgraded from prior RH releases), 
I didn't fully grasp an understanding of what it meant for production servers, 
and what ended up being an upgrade treadmill. For the servers I was rolling 
out, I found myself having to redo builds, sometimes from scratch, to build, 
test, re-test, re-build, till the server was guaranteed to be rock solid. then 
roll-out, and a short time later, having to do it all again.

I realised what FC was, but didn't really understand the committment that was 
required to upgrades when running it on so many servers. I even considered 
skipping even numbered releases and going with odd (fc2 skip, fc4 skip, etc). 
But in the end I sat down and looked at the bigger picture, and ending up 
settling with alternative RHEL releases, which satisfied my requirements to a 
tee.

Michael.

> FC == `uptime` < 270 days
> FC + FL == `uptime` < 500 days
> RHEL/SLES == `uptime` > 500 days
> 
> -- 
> Matthew Nuzum <matt at followers.net>
> www.followers.net - Makers of "Elite Content Management System"
> View samples of Elite CMS in action by visiting
> http://www.followers.net/portfolio/
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
------- End of Original Message -------



From rostetter at mail.utexas.edu  Fri Mar  4 04:25:46 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Thu,  3 Mar 2005 22:25:46 -0600
Subject: how to get started with helping the project [...]
In-Reply-To: <1109882195.13515.21.camel@blue>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
Message-ID: <1109910346.142cd32ac1449@mail.ph.utexas.edu>

Quoting Jim Popovitch <jimpop at yahoo.com>:

> So, why invest time and $$ in RH and/or Fedora if the phase-out process
> is not treated as sincerely as the roll-out?

It is treated equally to the roll out.  You seem to think the roll outs
are more professional than they are.
 
> All I'm saying is this:  Put the truth on the website.  If FL isn't

It is. You seem to read into it what you want, rather than what it says.

> meant to be relied upon, nor if it isn't meant to be used in production
> systems, nor if it isn't suppose to be quality support for EOL'ed RH
> systems... just put the truth on the website so that visitors have
> correct data.

FL is not a single entity.  It supports RHL 7.3, RHL 9, and FC1 at the
moment.  RHL 7.3 is considered by most to be production quality.  The
FL support for it is considered by most to be production quality, though
not fast enough for many.  RHL 9 is a subject of debate whether it is
production quality or not.  Hence the FL updates for it hold a similar
status.  FC is officially not meant to be production quality.  So FL support
for FC should not be considered production quality, as we're starting with
a non-production ready base.

You can't paint FL updates with a single brush.  Each release has its
own quality issues.

> It seems to me that this following paragraph from the website should be
> removed:
> 
>   "The goal of The Fedora Legacy Project is to work with the Linux
>    community to provide security and critical bug fix errata packages
>    for select End of Life Red Hat Linux and Fedora Core distributions.
>    This will allow for a longer effective life for those releases."

It states exactly the goal of the project, and as such should not be
removed from the site.  Perhaps you meant to say something should be
added to it?

> After all, the above goes counter to a lot of the comments expressed
> here today.

No, it does not, unless you mean your own comments.

> Notably the ones about "test it yourself" and "expecting
> anything else is unrealisticaly wrong."

This is pure twisting of people's words to suit your argument.
 
> -Jim P.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Fri Mar  4 04:40:55 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Thu,  3 Mar 2005 22:40:55 -0600
Subject: how to get started with helping the project [...]
In-Reply-To: <1109884466.12887.11.camel@jkeating2.hq.pogolinux.com>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
	<Pine.LNX.4.61.0503032246580.10083@netcore.fi>
	<20050303210630.GA4513@srv01.cluenet.de>
	<1109884466.12887.11.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1109911255.0b912eb713be4@mail.ph.utexas.edu>

Quoting Jesse Keating <jkeating at j2solutions.net>:

> On Thu, 2005-03-03 at 22:06 +0100, Daniel Roesen wrote:
> > The problem is that people who take security serious can't wait weeks
> > and months for security fixes to arrive from FL. And as that's
> > (security
> > fixes) all FL provides...

That is a fair and valid complaint.

> packages.  Fedora Legacy is part of VendorSec now, however to really act
> on any information I get from there, I would need to close community
> access to the bug and communicate privately with a very very select few
> about the issue.  I'm torn on this.  It would allow for potentially
> faster and more coordinated packages, but the community would have a lot
> less chance to do the QA and testing.  It is a very hard thing to do.
> What may happen is that we'll have testing packages ready at coordinated
> announce time, for the community to QA so that we can release shortly
> thereafter.  Is anybody opposed to this strategy?  It will still mean
> private bugs in bugzilla until ready for announcement.

I think that is a fine idea.  The community wants quick updates.  We also
want open QA.  I don't see a problem with someone creating a package before
the bug is opened (or to a private bug report), for whatever reason.

I still think anything would have to go through a public QA before being
published.  But I don't see why we can't get the people involved in the
VendorSec part to create and validate the initial package.  You just need
to have as many people in the VendorSec loop as you need minimum votes to
move the package to testing.

> > For me, FL is only of value if I can save time by just installing FL
> > RPMs instead of rolling my own security updates. But at least remotely
> > exploitable vulnerabilities require *immediate* fix so people can't
> > wait
> > weeks and months for FL to get into gear. So one has to backport or
> > install newer, fixed versions manually. So no time saved at all.

Or buy a pay service such a that from Progeny.

> > I'm surely NOT picking on the FL project. It's all free (as in "beer")
> > after all, and the intentions are very noble. But it's IMHO a fact
> > that
> > current procedures (and probably lack of community manpower) lead to
> > unacceptable delays which renders the whole project's point somewhat
> > moot.

Well, it renders the current value of it very low.  But that doesn't mean
it can't grow to be a quick, reliable project in the future.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Fri Mar  4 05:10:01 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Thu,  3 Mar 2005 23:10:01 -0600
Subject: how to get started with helping the project [...]
In-Reply-To: <1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
Message-ID: <1109913001.f6e9b407db7a7@mail.ph.utexas.edu>

Quoting Marcus Lauer <marcus.lauer at nyu.edu>:

>         As a lurker myself, I'm more inclined to side with Mr.
> Popovitch.  His original criticisms about there not being an e-mail
> about the website going down and about there not being an alternate
> leader in case something happens to Mr. Keating's ability to communicate
> aren't unreasonable. 

I agree.  I wish there was an email sent out about the web site problems
also.

> That doesn't mean that they're right, but just

I think his point was correct, but the way he went about arguing it
caused it to not to be as helpful as we'd have wanted.

> that they're the sort of thing which should lead to a discussion.  I
> mean, what would happen to the project if Mr. Keating just disappeared
> one day?  Is there any contingency plan in place at all?

Good question.  I think the project would recover and carry on, but I don't
know there are any plans on how it would do that, and without such plans
it would take a much longer time to recover.

>         Again, while I don't agree with Mr. Popovitch's position on
> everything, I think that he has made some legitimate criticisms of the
> project and I think that they got ignored 

I don't think they were ignored.  Rather, it snowballed into some idiotic
arguing which prevents any action from being taken on his original complaints.

> project.  Criticism can be a valuable contribution, and criticism coming
> from outside of the core group working on a project can help illustrate
> problems which they might miss.

Agreed.  Well argued, polite criticism is even better. :)
 
>         For example, take Mr. Popovitch's Bugzilla/Midnight Commander
> comment.  I'm inclined to agree.

With what part of it?

> The one time I tried to submit a bug
> to Bugzilla, I couldn't figure out how.

Then you need to ask for help, and ask for us to either create documentation
to meet your needs, or provide a link to such information.

> Admittedly, I didn't spend a
> whole lot of time on it, but I did find the time to figure out that bug
> in some detail so that I could report it.

It used to be stated in the docs, and has been covered many times on the
mailing list, that posting the bug report to the mailing list is
a valid alternative to using the bugzilla system.  If you have info,
and can't figure out bugzilla, e-mail it to the list.

I'll update my TODO list to include making this clear once again in the
docs, and it seems to have been edited out over time.

> More recently, when I tried
> to figure out why nfs-utils was in testing I couldn't find anything on
> it.  Every now and then I'm willing to contribute to FL, but I'm having
> trouble.

I agree.  All I can do is say two things, which you probably don't want
to hear, but it is really all I can say to help:

1) Ask for help on the mailing list
2) Try helping in another fashion (we could use help in other areas).

> Mr. Popovitch described this aspect of FL as "painful" and
> "difficult" (and I notice that the thread was simply dropped after that
> post).

Not if you count my replies to it.

> I would be more specific in saying that perhaps it should be a
> goal of the FL project to put something more detailed than just "Report
> your test results in the Bugzilla system." on the wiki so that the
> newbies have an easier time of picking it up.

I'll put the mailing list alternative statement on my TODO list.

> I suspect that this is
> the sort of thing that a core group on a project would miss, in this
> case because they all know how to use Bugzilla already and think it's
> easy.

No.  If you go back to the start of the project, you'll find long threads
of me asking how to use bugzilla, wiki, irq, pgp signatures, etc.  I may be
part of the supposed "core group" but I had to learn all this too.  And I
don't think any of it is easy to learn.  That doesn't mean I don't think
it is easy to participate in the project though ;)
 
> and that's great, but are they really unwilling to listen to people who
> say "things could be better, here's how"?  Especially coming from people
> who _have_ done at least a little work for FL?  I sure hope not.  One of

I think you will find FL very supportive of nice, polite criticism.
Not everyone in FL.  Maybe not even most of them.  But as a group,
you will find that the criticism is taken and used.  Sometimes it
may not seem like it.  Sometimes it takes time.

>         Again, when the hard feelings from this flamewar have left
> everyone, I hope we can all go back and think about what has been said.
> The FL project is not perfect.  There are criticisms of it to be made,
> and I think that some of the ones made this time were legit, or at least
> worth discussing.

Agreed.  But, the danger is that it will get lost in the other stupid
arguments which take up much more bandwidth, and much more of FL's time,
than the actual valid criticisms do.

-- 
Eric Rostetter



From jimpop at yahoo.com  Fri Mar  4 13:49:27 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Fri, 04 Mar 2005 08:49:27 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
Message-ID: <1109944167.14766.21.camel@blue>

On Thu, 2005-03-03 at 23:10 -0600, Eric Rostetter wrote:
> >         Again, while I don't agree with Mr. Popovitch's position on
> > everything, I think that he has made some legitimate criticisms of the
> > project and I think that they got ignored 
> 
> I don't think they were ignored.  Rather, it snowballed into some idiotic
> arguing which prevents any action from being taken on his original complaints.

It's worth pointing out that, other than Marcus, there still is no
discussion of the points I raised, rather now generalized discussions
about how the message was delivered.   Fine, if you don't like my
delivery, at least do something wrt the message.

-Jim P.






From rostetter at mail.utexas.edu  Fri Mar  4 14:54:21 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Fri,  4 Mar 2005 08:54:21 -0600
Subject: how to get started with helping the project [...]
In-Reply-To: <1109944167.14766.21.camel@blue>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
Message-ID: <1109948061.d894dc9b9686d@mail.ph.utexas.edu>

Quoting Jim Popovitch <jimpop at yahoo.com>:

> On Thu, 2005-03-03 at 23:10 -0600, Eric Rostetter wrote:
> > >         Again, while I don't agree with Mr. Popovitch's position on
> > > everything, I think that he has made some legitimate criticisms of the
> > > project and I think that they got ignored
> >
> > I don't think they were ignored.  Rather, it snowballed into some idiotic
> > arguing which prevents any action from being taken on his original
> complaints.
> 
> It's worth pointing out that, other than Marcus, there still is no
> discussion of the points I raised, rather now generalized discussions
> about how the message was delivered.   Fine, if you don't like my
> delivery, at least do something wrt the message.
> 
> -Jim P.

What exactly do you expect us to accomplish is two days?
 
Maybe if you put together a "TODO" list for us of things you'd like to
see done?   A start might be:

* Set up a communications structure to notify the community of important events
* Create a backup plan should Jesse get run over by a bus
* Write some documentation about things unrelated to the project like the
  production quality of various RHL and FC releases.
* Write some docs about using Bugzilla (may have to wait until Bugzilla
  conversion from fedora.us to redhat.com).

Please add other ideas, so we can get them into the TODO list (or even 
a bugzilla bug ticket).

-- 
Eric Rostetter



From jimpop at yahoo.com  Fri Mar  4 15:10:32 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Fri, 04 Mar 2005 10:10:32 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109948061.d894dc9b9686d@mail.ph.utexas.edu>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
Message-ID: <1109949032.14766.28.camel@blue>

On Fri, 2005-03-04 at 08:54 -0600, Eric Rostetter wrote:
> What exactly do you expect us to accomplish is two days?

Some discussion about the message not the delivery.

>  
> Maybe if you put together a "TODO" list for us of things you'd like to
> see done?   A start might be:
>
> * Set up a communications structure to notify the community of important events
> * Create a backup plan should Jesse get run over by a bus
> * Write some documentation about things unrelated to the project like the
>   production quality of various RHL and FC releases.
> * Write some docs about using Bugzilla (may have to wait until Bugzilla
>   conversion from fedora.us to redhat.com).

That's funny, some of those are the very things I *have* already listed.
I guess you were too busy complaining about me complaining to have
noticed.

I did say that there needed to be more structure, and I asked Jesse to
NOT work on future builds until he set this up.

I did ask for better documentation about the processes and procedures,
and not just better docs but more clarification so that more people can
actually do things to help out. 

-Jim P.






From marcus.lauer at nyu.edu  Fri Mar  4 15:16:06 2005
From: marcus.lauer at nyu.edu (Marcus Lauer)
Date: 04 Mar 2005 10:16:06 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109949032.14766.28.camel@blue>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
Message-ID: <1109949366.13843.17.camel@bizzaro.psych.nyu.edu>

On Fri, 2005-03-04 at 10:10, Jim Popovitch wrote:
> > Maybe if you put together a "TODO" list for us of things you'd like to
> > see done?   A start might be:
> >
> > * Set up a communications structure to notify the community of important events
> > * Create a backup plan should Jesse get run over by a bus
> > * Write some documentation about things unrelated to the project like the
> >   production quality of various RHL and FC releases.
> > * Write some docs about using Bugzilla (may have to wait until Bugzilla
> >   conversion from fedora.us to redhat.com).
> 
> That's funny, some of those are the very things I *have* already listed.
> I guess you were too busy complaining about me complaining to have
> noticed.

        I think that's why Mr. Rostetter suggested that you make a
list.  The "discussion" was such a mess that maybe a nice clear list of
what you'd like to see done would help.

-- 

Marcus Lauer
Lab Manager for the Curtis Lab
6 Washington Square, Rooms 875 and 876
Psychology Department, NYU
Phone: (212)998-8347
http://psych.nyu.edu/curtislab/



From jkeating at j2solutions.net  Fri Mar  4 15:18:20 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 04 Mar 2005 07:18:20 -0800
Subject: how to get started with helping the project [...]
In-Reply-To: <1109949032.14766.28.camel@blue>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
Message-ID: <1109949500.4902.70.camel@localhost.localdomain>

On Fri, 2005-03-04 at 10:10 -0500, Jim Popovitch wrote:
> That's funny, some of those are the very things I *have* already
> listed.
> I guess you were too busy complaining about me complaining to have
> noticed.

No, we noticed, and we didn't disagree that some of the things you
wanted would be nice.  What we disagree with is the attitude you show,
and the idea you have below...

> I did say that there needed to be more structure, and I asked Jesse to
> NOT work on future builds until he set this up.

I hope you mean me personally, and not the Legacy project.  Stopping
everything just to build infrastructure is completely insane.  As I've
stated before, I haven't worked on a build for close to a year, so this
above is a moot point.

> I did ask for better documentation about the processes and procedures,
> and not just better docs but more clarification so that more people
> can
> actually do things to help out

Help us clarify.

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050304/ba4e6ec5/attachment.sig>

From jimpop at yahoo.com  Fri Mar  4 15:21:52 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Fri, 04 Mar 2005 10:21:52 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109949366.13843.17.camel@bizzaro.psych.nyu.edu>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
	<1109949366.13843.17.camel@bizzaro.psych.nyu.edu>
Message-ID: <1109949712.14766.34.camel@blue>

On Fri, 2005-03-04 at 10:16 -0500, Marcus Lauer wrote:
>
>         I think that's why Mr. Rostetter suggested that you make a
> list.  The "discussion" was such a mess that maybe a nice clear list of
> what you'd like to see done would help.

OK, good point.  I have been overly critical, and a lot of that is
directed towards what appears to me to be apathy, so shame on me for not
being more detailed.  I will take the task of trying to define a
structure and associated responsibilities list.  This may take a few
days, but the weekend is coming up.  Everyone please feel free to pass
on your opinions on what you think is needed or what isn't needed and I
will try to release a plan over the weekend.

-Jim P.



From dsccable at comcast.net  Fri Mar  4 16:23:09 2005
From: dsccable at comcast.net (David Curry)
Date: Fri, 04 Mar 2005 11:23:09 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109949712.14766.34.camel@blue>
References: <421E9E0E.1030000@videotron.ca>	<200503031453.05137.guallar@easternrad.com>	<1109880271.13515.1.camel@blue>	<200503031518.53988.guallar@easternrad.com>	<1109882195.13515.21.camel@blue>
	<42277C85.506@securityspace.com>	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>	<1109944167.14766.21.camel@blue>	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>	<1109949032.14766.28.camel@blue>	<1109949366.13843.17.camel@bizzaro.psych.nyu.edu>
	<1109949712.14766.34.camel@blue>
Message-ID: <42288B6D.7010305@comcast.net>

Jim Popovitch wrote:

>On Fri, 2005-03-04 at 10:16 -0500, Marcus Lauer wrote:
>  
>
>>        I think that's why Mr. Rostetter suggested that you make a
>>list.  The "discussion" was such a mess that maybe a nice clear list of
>>what you'd like to see done would help.
>>    
>>
>
>OK, good point.  I have been overly critical, and a lot of that is
>directed towards what appears to me to be apathy, so shame on me for not
>being more detailed.  I will take the task of trying to define a
>structure and associated responsibilities list.  This may take a few
>days, but the weekend is coming up.  Everyone please feel free to pass
>on your opinions on what you think is needed or what isn't needed and I
>will try to release a plan over the weekend.
>
>-Jim P.
>
>--
>fedora-legacy-list mailing list
>fedora-legacy-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-legacy-list
>
>  
>
This from a newbie and another lurker who has not made a single 
contribution to FL.

I suggest that you think in terms of working up a sturcture and 
associated responsibilities list PROPOSAL rahter than  a definition.

Speaking bluntly, reading all of the exchanges on the subject thread 
leaves me with one overriding impression - that you want to be King.

Getting started helping with the project is not the easiest thing in the 
world to do.  (But, it is far from the hardest either.)

I find no basis in fact for your assertions that FL misleads people.  
Had I been on the receiving end of many of your remarks, I would have 
invited you to stuff your opinions where the sun don't shine.



From rostetter at mail.utexas.edu  Fri Mar  4 16:59:46 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Fri,  4 Mar 2005 10:59:46 -0600
Subject: how to get started with helping the project [...]
In-Reply-To: <1109949032.14766.28.camel@blue>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
Message-ID: <1109955586.f28f0b540da17@mail.ph.utexas.edu>

Quoting Jim Popovitch <jimpop at yahoo.com>:

> On Fri, 2005-03-04 at 08:54 -0600, Eric Rostetter wrote:
> > What exactly do you expect us to accomplish is two days?
> 
> Some discussion about the message not the delivery.

I've tried.  You keep moving the conversation off topic with new arguments
about all kinds of different things.

> > Maybe if you put together a "TODO" list for us of things you'd like to
> > see done?   A start might be:
> >
> > * Set up a communications structure to notify the community of important
> events
> > * Create a backup plan should Jesse get run over by a bus
> > * Write some documentation about things unrelated to the project like the
> >   production quality of various RHL and FC releases.
> > * Write some docs about using Bugzilla (may have to wait until Bugzilla
> >   conversion from fedora.us to redhat.com).
> 
> That's funny, some of those are the very things I *have* already listed.

No, it's not funny.  What I was trying to do was make a TODO list based on
your postings and the responses to them.  What would be funny would be if
none of your points showed up on my list.

> I guess you were too busy complaining about me complaining to have
> noticed.

What?  I tried to make a TODO list of what you and others wanted done. A
TODO list is a list of short descriptions of what needs to be done.

What you submitted was paragraph after paragraph of stuff.  That isn't a 
TODO list.

What I've asked you to do is to try to make a TODO list containing what
you want done.  And to help you, I started one including the ideas from the
mailing list from the last couple of days.  What I expect from you and
others is not to insult me or my list, but to help improve it.  To add
entries I've missed,  clarify entries I've not made clear, delete things
if they can't be done for some reason.

> I did say that there needed to be more structure, and I asked Jesse to
> NOT work on future builds until he set this up.

Okay, that won't work.  First, you need to define the type of structure
you want to see.  We can't just read your mind and setup a structure to
meet your needs without your help.  Saying we need structure doesn't
really help any.  We already have structure.  If you don't like the
structure, you need to define how it is insufficient, not just say
we "need structure."

Second, we can't stop a project like this (stop delivering the goods) because
one person isn't happy with our structure.  That would be like Red Hat stopping
all support for RHEL because myself and some people I know don't like their
structure (and we don't).  But others have agreed with the structure, and 
Red Hat must keep delivering to them, not matter what my friends and I may
think.  They can make structural changes while still delivering the product.

> I did ask for better documentation about the processes and procedures,
> and not just better docs but more clarification so that more people can
> actually do things to help out.

Okay, you want "better documentation about the process and procedures" but
I really don't know what that means.  Can you define what you mean in
simple, bullet type style?

I'm confused how you separate "better docs" from "more clarification so
that more people can actually do things to help out."  The point of 
better docs would be to clarify things, no?

> -Jim P.

You seem determined to thwart any progress on the issues you have raised.
I simply don't understand your tactics.

-- 
Eric Rostetter



From jimpop at yahoo.com  Fri Mar  4 17:08:01 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Fri, 04 Mar 2005 12:08:01 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <42288B6D.7010305@comcast.net>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
	<1109949366.13843.17.camel@bizzaro.psych.nyu.edu>
	<1109949712.14766.34.camel@blue>  <42288B6D.7010305@comcast.net>
Message-ID: <1109956081.3339.9.camel@blue>

On Fri, 2005-03-04 at 11:23 -0500, David Curry wrote:
>
> This from a newbie and another lurker who has not made a single 
> contribution to FL.
> 
> I suggest that you think in terms of working up a sturcture and 
> associated responsibilities list PROPOSAL rahter than  a definition.
> 
> Speaking bluntly, reading all of the exchanges on the subject thread 
> leaves me with one overriding impression - that you want to be King.

That is the furthest from the truth.  There does need to be a king, and
I want there to be a king.  Unfortunately no one is stepping up to be
king, thus there is a big void in leadership.

> Getting started helping with the project is not the easiest thing in the 
> world to do.  (But, it is far from the hardest either.)

It's not impossible, but it's also not intuitive or conducive to
participation.  Lack of participation will overload Jesse, he then gets
less interested, and the process will ultimately fail.  We all benefit
by more people getting involved rather than moving on.

> I find no basis in fact for your assertions that FL misleads people.  
> Had I been on the receiving end of many of your remarks, I would have 
> invited you to stuff your opinions where the sun don't shine.

:-)  I don't aim to make friends, only results.

-Jim P.






From beartooth at adelphia.net  Fri Mar  4 16:37:01 2005
From: beartooth at adelphia.net (beartooth)
Date: Fri, 04 Mar 2005 11:37:01 -0500
Subject: Error: ... correct GPG keys installed?
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109874371.11173.68.camel@blue>
	<20050303201236.GA16853@jadzia.bu.edu>
Message-ID: <pan.2005.03.04.16.37.01.159394@adelphia.net>

On Thu, 03 Mar 2005 15:12:36 -0500, Matthew Miller wrote:

> On Thu, Mar 03, 2005 at 01:26:10PM -0500, Jim Popovitch wrote:
>>    gpg --list-keys
> 
> While this is generally right for gpg, Alexander Dalloz is correct in that
> it doesn't apply to rpm package signatures, which is what yum is checking.
> Instead, you need to have the right gpg key in your RPM database -- check
> with `rpm -q gpg-pubkey`, and import with `rpm --import
> Fedora-Legacy-GPG-KEY`.

I tried both, but I don't know what to make of the output. I get : 
                         =====
[root at localhost root]# rpm -q gpg-pubkey
gpg-pubkey-4f2a6fd2-3f9d9d3b
gpg-pubkey-db42a60e-37ea5438
[root at localhost root]# rpm --import Fedora-Legacy-GPG-KEY
error: Fedora-Legacy-GPG-KEY: import read failed.
[root at localhost root]#
                          =====
-- 
Beartooth Implacable, Linux Evangelist & Gadfly
neo-redneck, curmudgeonly codger with FC1 & YDL 4.0
Pine 4.61, Pan 0.14.2; Privoxy 3.0.1; Opera 7.54, Firefox 1.0
Bear in mind that I have little idea what I am talking about.




From beartooth at adelphia.net  Fri Mar  4 16:56:38 2005
From: beartooth at adelphia.net (beartooth)
Date: Fri, 04 Mar 2005 11:56:38 -0500
Subject: Error: ... correct GPG keys installed?
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109873341.9846.447.camel@serendipity.dogma.lan>
	<pan.2005.03.03.19.43.46.910288@adelphia.net>
	<1109880833.9846.457.camel@serendipity.dogma.lan>
Message-ID: <pan.2005.03.04.16.56.35.789396@adelphia.net>

On Thu, 03 Mar 2005 21:13:53 +0100, Alexander Dalloz wrote:

> Am Do, den 03.03.2005 schrieb beartooth um 20:43:
> 
>> > Please tell us:
>> > 
>> > a) which GPG is claimed to be missing b) for which packages from
>> > where (repository) c) output of following single line command: for
>> > key in $(rpm -qa | grep pubkey); do rpm -qi ${key} | head -10; done
>> 
>> I'm sorry : I don't know how to get the answers to a) nor b) -- but I
>> did do c) immediately after the things Jim Popovich had suggested --
>> and got this :
> 
>  [ snipped ]
> 
> rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY

I just did that (and should've read all the new posts before asking
essentially that above), got simply the root prompt back -- no messages --
and then tried yum update again. That gave me the usual list of actions
(snipped) and then this :
                         =====
Is this ok [y/N]: y
warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 8df56d05
Error: Could not find the GPG Key necessary to validate pkg
/var/cache/yum/fedora-stable/packages/perl-DateManip-5.42-0.fdr.2.a.1.noarch.rpm
Error: You may want to run yum clean or remove the file:
 /var/cache/yum/fedora-stable/packages/perl-DateManip-5.42-0.fdr.2.a.1.noarch.rpm
Error: You may also check that you have the correct GPG keys installed
[root at localhost root]#
                         =====
Btw, I have many times tried both running yum clean and removing whichever
file got objected to, upon getting these messages, and never had either
make it work.

Perhaps I should mention, or remind people, that the yum.conf file I have
goes to several repos. Dunno if that's relevant or not. Will it help, for
instance, if I post all the URLs it contains?

-- 
Beartooth Implacable, Linux Evangelist & Gadfly
neo-redneck, curmudgeonly codger with FC1 & YDL 4.0
Pine 4.61, Pan 0.14.2; Privoxy 3.0.1; Opera 7.54, Firefox 1.0
Bear in mind that I have little idea what I am talking about.




From brian.t.brunner at gai-tronics.com  Fri Mar  4 17:16:53 2005
From: brian.t.brunner at gai-tronics.com (Brian T. Brunner)
Date: Fri, 04 Mar 2005 09:16:53 -0800
Subject: how to get started with helping the project [...]
Message-ID: <s2282797.062@CRPSPKWANW02-IA.hubbell.com>


To understand Jim, mark the difference between the tree-shaker 
(e.g. Jim and myself) and the jelly-maker (the patient, persistent contributors 
to the FL project).  Tree-shakers are good for criticism, some of it quite
thoughtful and poignant.  Jelly-makers do the implementation with
care for the details.

My recognition of the difference between the two is why I've been (mostly) quiet on this list.

The key for discerning is the lack of the "how about if I join and help by doing..."


Brian Brunner
brian.t.brunner at gai-tronics.com
(610)796-5838

>>> rostetter at mail.utexas.edu 03/04/05 11:59AM >>>
Quoting Jim Popovitch <jimpop at yahoo.com>:

> On Fri, 2005-03-04 at 08:54 -0600, Eric Rostetter wrote:
> > What exactly do you expect us to accomplish is two days?
> 
> Some discussion about the message not the delivery.

I've tried.  You keep moving the conversation off topic with new arguments
about all kinds of different things.

> I did ask for better documentation about the processes and procedures,
> and not just better docs but more clarification so that more people can
> actually do things to help out.

Okay, you want "better documentation about the process and procedures" but
I really don't know what that means.  Can you define what you mean in
simple, bullet type style?

I'm confused how you separate "better docs" from "more clarification so
that more people can actually do things to help out."  The point of 
better docs would be to clarify things, no?

> -Jim P.

You seem determined to thwart any progress on the issues you have raised.
I simply don't understand your tactics.

-- 
Eric Rostetter

--
fedora-legacy-list mailing list
fedora-legacy-list at redhat.com 
http://www.redhat.com/mailman/listinfo/fedora-legacy-list

*******************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept
for the presence of computer viruses.

www.hubbell.com - Hubbell Incorporated



From jkeating at j2solutions.net  Fri Mar  4 17:18:24 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 04 Mar 2005 09:18:24 -0800
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <pan.2005.03.04.16.56.35.789396@adelphia.net>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109873341.9846.447.camel@serendipity.dogma.lan>
	<pan.2005.03.03.19.43.46.910288@adelphia.net>
	<1109880833.9846.457.camel@serendipity.dogma.lan>
	<pan.2005.03.04.16.56.35.789396@adelphia.net>
Message-ID: <1109956705.12887.50.camel@jkeating2.hq.pogolinux.com>

On Fri, 2005-03-04 at 11:56 -0500, beartooth wrote:
> I just did that (and should've read all the new posts before asking
> essentially that above), got simply the root prompt back -- no
> messages --

Thats good.  You've now imported the Legacy key.

> and then tried yum update again. That gave me the usual list of
> actions
> (snipped) and then this :
>                          =====
> Is this ok [y/N]: y
> warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 8df56d05
> Error: Could not find the GPG Key necessary to validate pkg
> /var/cache/yum/fedora-stable/packages/perl-
> DateManip-5.42-0.fdr.2.a.1.noarch.rpm
> Error: You may want to run yum clean or remove the file:
>  /var/cache/yum/fedora-stable/packages/perl-
> DateManip-5.42-0.fdr.2.a.1.noarch.rpm
> Error: You may also check that you have the correct GPG keys installed
> [root at localhost root]#

Fedora-stable doesn't sound like a Fedora Legacy repo.  Please check
what repo is labeled 'fedora-stable' in your yumconf.  You'll have to
get THEIR gpg key as well.

                         =====
> Btw, I have many times tried both running yum clean and removing
> whichever
> file got objected to, upon getting these messages, and never had
> either
> make it work.
> 
> Perhaps I should mention, or remind people, that the yum.conf file I
> have
> goes to several repos. Dunno if that's relevant or not. Will it help,
> for
> instance, if I post all the URLs it contains?

Yes.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From dsccable at comcast.net  Fri Mar  4 17:27:39 2005
From: dsccable at comcast.net (David Curry)
Date: Fri, 04 Mar 2005 12:27:39 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109956081.3339.9.camel@blue>
References: <421E9E0E.1030000@videotron.ca>	<200503031453.05137.guallar@easternrad.com>	<1109880271.13515.1.camel@blue>	<200503031518.53988.guallar@easternrad.com>	<1109882195.13515.21.camel@blue>
	<42277C85.506@securityspace.com>	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>	<1109944167.14766.21.camel@blue>	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>	<1109949032.14766.28.camel@blue>	<1109949366.13843.17.camel@bizzaro.psych.nyu.edu>	<1109949712.14766.34.camel@blue>
	<42288B6D.7010305@comcast.net> <1109956081.3339.9.camel@blue>
Message-ID: <42289A8B.7060303@comcast.net>

Jim Popovitch wrote:

>On Fri, 2005-03-04 at 11:23 -0500, David Curry wrote:
>  
>
>>I find no basis in fact for your assertions that FL misleads people.  
>>Had I been on the receiving end of many of your remarks, I would have 
>>invited you to stuff your opinions where the sun don't shine.
>>    
>>
>
>:-)  I don't aim to make friends, only results.
>
>-Jim P.
>
>  
>
Results you have achieved in pursuing subject thread are 
straightforward.  You have documented for others on the list a case 
study of how to render oneself totally ineffective.



From jimpop at yahoo.com  Fri Mar  4 17:26:53 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Fri, 04 Mar 2005 12:26:53 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109955586.f28f0b540da17@mail.ph.utexas.edu>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
	<1109955586.f28f0b540da17@mail.ph.utexas.edu>
Message-ID: <1109957213.3339.25.camel@blue>

On Fri, 2005-03-04 at 10:59 -0600, Eric Rostetter wrote:
>
> Okay, you want "better documentation about the process and procedures" but
> I really don't know what that means.  Can you define what you mean in
> simple, bullet type style?

Yes, and I will do so over the weekend as previously stated.

> I'm confused how you separate "better docs" from "more clarification so
> that more people can actually do things to help out."  The point of 
> better docs would be to clarify things, no?

There is a need for good documentation as others have pointed out.
Simply saying "login to bugtraq and search" or "test then post a verify"
isn't enough.  OK, so I've not provided a complete replacement for the
existing documentation, that doesn't mean there isn't room for
improvement.  Prior to me raising the issue, the main FL participants
thought the documentation was good enough.

> You seem determined to thwart any progress on the issues you have raised.
> I simply don't understand your tactics.

My tactics are this:  IMHO what I see now, wrt FL, isn't suitable for a
production environment where systems require robustly tested patches in
a timely fashion.

FL caused me to be forced to remove PHP from my users due to the PHP
support fiasco that ensued here.  I am not going to sit idly by waiting
for an SSH or FTP vulnerability to see if FL has matured.

I have three choices:

  1) Insist that FL matures and becomes more structured and reformed.
      (in the works, needs more support)

  2) Move to another distribution.
      (under consideration internally, but honestly quite drastic) 

  3) Roll our own patches/updates
      (doesn't scale well on nights and weekends)

-Jim P.





From jimpop at yahoo.com  Fri Mar  4 17:37:29 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Fri, 04 Mar 2005 12:37:29 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <42289A8B.7060303@comcast.net>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
	<1109949366.13843.17.camel@bizzaro.psych.nyu.edu>
	<1109949712.14766.34.camel@blue> <42288B6D.7010305@comcast.net>
	<1109956081.3339.9.camel@blue>  <42289A8B.7060303@comcast.net>
Message-ID: <1109957849.3339.28.camel@blue>

On Fri, 2005-03-04 at 12:27 -0500, David Curry wrote:
> Results you have achieved in pursuing subject thread are 
> straightforward.  You have documented for others on the list a case 
> study of how to render oneself totally ineffective.

Cute.

Unfortunately this isn't a cutesy project.  People are trying to depend
on FL, not simply enjoy it.

-Jim P.





From rostetter at mail.utexas.edu  Fri Mar  4 17:41:51 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Fri,  4 Mar 2005 11:41:51 -0600
Subject: how to get started with helping the project [...]
In-Reply-To: <1109957213.3339.25.camel@blue>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
	<1109955586.f28f0b540da17@mail.ph.utexas.edu>
	<1109957213.3339.25.camel@blue>
Message-ID: <1109958111.29f8c1f643aac@mail.ph.utexas.edu>

Quoting Jim Popovitch <jimpop at yahoo.com>:

> There is a need for good documentation as others have pointed out.

Yes, and if you check the archives, you will find me asking multiple times
for people to help write new documentation, and even more often for people
to read the existing docs and make comments about what is missing/unclear/etc.

People have not responded to such requests most of the time, hence no changes
to the docs.

> Simply saying "login to bugtraq and search" or "test then post a verify"
> isn't enough.

I really don't know much about using bugzilla (which I assume you mean
when you say bugtraq) so it is hard for me to write good docs on it.
We almost need someone who is fluent in bugzilla to write them, or I need
to just point to someone elses HOWTO docs instead.

> OK, so I've not provided a complete replacement for the
> existing documentation, that doesn't mean there isn't room for
> improvement.

I'm not asking for a complete replacement of the existing docs.  Or even
any replacment of the existing docs.  I'm simply asking for you to define
what you want done.

> Prior to me raising the issue, the main FL participants
> thought the documentation was good enough.

No.  I don't know of anyone who thinks are docs are good enough, nor
that think they are complete.  We've regularly solicited help with the
docs, we've just not received much help with them.
 
> > You seem determined to thwart any progress on the issues you have raised.
> > I simply don't understand your tactics.
> 
> My tactics are this:  IMHO what I see now, wrt FL, isn't suitable for a
> production environment where systems require robustly tested patches in
> a timely fashion.

I agree we have not been meeting the timely fashion part.  Otherwise, I
have no problem with the project.  The way to meet the "timely fashion"
part is via participation.  The way to meet the "timely fashion" part
in a "timely fashion" is via constructive, helpful, non-combative 
participation.

> I have three choices:
> 
>   1) Insist that FL matures and becomes more structured and reformed.
>       (in the works, needs more support)

Yes, needs more participation and help.  Certainly this is a goal of
everyone involved in FL.
 
>   2) Move to another distribution.
>       (under consideration internally, but honestly quite drastic)

That totally depends on your setup, needs, and policies.

>   3) Roll our own patches/updates
>       (doesn't scale well on nights and weekends)

Or use other people's updates/patches, or pay for updates/patches.  You
have lots of options here.

> -Jim P.

-- 
Eric Rostetter



From jkeating at j2solutions.net  Fri Mar  4 18:09:42 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 04 Mar 2005 10:09:42 -0800
Subject: how to get started with helping the project [...]
In-Reply-To: <1109958111.29f8c1f643aac@mail.ph.utexas.edu>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
	<1109955586.f28f0b540da17@mail.ph.utexas.edu>
	<1109957213.3339.25.camel@blue>
	<1109958111.29f8c1f643aac@mail.ph.utexas.edu>
Message-ID: <1109959782.12887.53.camel@jkeating2.hq.pogolinux.com>

On Fri, 2005-03-04 at 11:41 -0600, Eric Rostetter wrote:
> I really don't know much about using bugzilla (which I assume you mean
> when you say bugtraq) so it is hard for me to write good docs on it.
> We almost need someone who is fluent in bugzilla to write them, or I
> need
> to just point to someone elses HOWTO docs instead.

We are moving to Red Hat's bugzilla system very soon, so these docs will
need to be rewritten.  See my request for help I sent earlier.  I will
play an active role in revamping these docs for the new bugzilla system.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From drees at greenhydrant.com  Fri Mar  4 19:07:25 2005
From: drees at greenhydrant.com (David Rees)
Date: Fri, 4 Mar 2005 11:07:25 -0800 (PST)
Subject: how to get started with helping the project [...]
In-Reply-To: <1109957213.3339.25.camel@blue>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
	<1109955586.f28f0b540da17@mail.ph.utexas.edu>
	<1109957213.3339.25.camel@blue>
Message-ID: <4299.208.48.139.172.1109963245.squirrel@www.greenhydrant.com>

On Fri, March 4, 2005 9:26 am, Jim Popovitch said:
>
> My tactics are this:  IMHO what I see now, wrt FL, isn't suitable for a
> production environment where systems require robustly tested patches in
> a timely fashion.
>
> FL caused me to be forced to remove PHP from my users due to the PHP
> support fiasco that ensued here.  I am not going to sit idly by waiting
> for an SSH or FTP vulnerability to see if FL has matured.
>
> I have three choices:
>
>   1) Insist that FL matures and becomes more structured and reformed.
>       (in the works, needs more support)

So far your "insisting" has resulted in pretty much a flame fest and hand
waving without achieving much if any real work.

If you need things like PHP security updates to get out in a timely
fashion, you need to help with the QA process there.  There isn't a magic
team out there doing the work for free and getting perfect updates out in
minutes or hours, it takes people work to get these things done.

FL has done a great job given the resources available.

Any "tardiness" issuing security updates that I've seen has been a result
of insufficient resources.  There are plenty of docs already in place, but
it isn't a sexy or fun job to implement, test and release security updates
much less learn how to do them.  A bit of a catch 22:  You need resources
to publish security updates, but the resources aren't there because it's a
PITA to do the work.

Steps have been taken to reduce the PITA factor, but in the end there's
only so much you can do without having people dedicated to working on them
24/7.

-Dave



From jimpop at yahoo.com  Fri Mar  4 19:18:08 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Fri, 04 Mar 2005 14:18:08 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <4299.208.48.139.172.1109963245.squirrel@www.greenhydrant.com>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
	<1109955586.f28f0b540da17@mail.ph.utexas.edu>
	<1109957213.3339.25.camel@blue>
	<4299.208.48.139.172.1109963245.squirrel@www.greenhydrant.com>
Message-ID: <1109963888.4517.3.camel@blue>

On Fri, 2005-03-04 at 11:07 -0800, David Rees wrote:
> A bit of a catch 22:  You need resources to publish security 
> updates, but the resources aren't there because it's a
> PITA to do the work.

No offense, but that's not a catch-22.  A catch-22 would be needing
resources to publish security updates, but the resources aren't there
because of the lack of timely reliable security updates.  (quite
accurate of FL's current situation)

-Jim P.







From jimpop at yahoo.com  Fri Mar  4 19:20:18 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Fri, 04 Mar 2005 14:20:18 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109963888.4517.3.camel@blue>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
	<1109955586.f28f0b540da17@mail.ph.utexas.edu>
	<1109957213.3339.25.camel@blue>
	<4299.208.48.139.172.1109963245.squirrel@www.greenhydrant.com>
	<1109963888.4517.3.camel@blue>
Message-ID: <1109964019.4517.5.camel@blue>

On Fri, 2005-03-04 at 14:18 -0500, Jim Popovitch wrote:
> On Fri, 2005-03-04 at 11:07 -0800, David Rees wrote:
> > A bit of a catch 22:  You need resources to publish security 
> > updates, but the resources aren't there because it's a
> > PITA to do the work.
> 
> No offense, but that's not a catch-22.  A catch-22 would be needing
> resources to publish security updates, but the resources aren't there
> because of the lack of timely reliable security updates.  (quite
> accurate of FL's current situation)

I guess I can re-read your catch-22 to see that you probably were trying
to say the same thing with your "PITA" comment.

-Jim P.






From rostetter at mail.utexas.edu  Fri Mar  4 19:44:55 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Fri,  4 Mar 2005 13:44:55 -0600
Subject: how to get started with helping the project [...]
In-Reply-To: <1109872770.4902.50.camel@localhost.localdomain>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue>
	<1109867472.4902.12.camel@localhost.localdomain>
	<1109870663.11173.33.camel@blue>
	<1109871702.4902.34.camel@localhost.localdomain>
	<1109872461.11173.52.camel@blue>
	<1109872770.4902.50.camel@localhost.localdomain>
Message-ID: <1109965495.6143b8bc384bb@mail.ph.utexas.edu>

Quoting Jesse Keating <jkeating at j2solutions.net>:

> I want people using FL to know what they're getting into, and to clearly
> know what we're providing for them.  We're not an RHEL alternative.
> We're a community project that's trying to provide security updates to
> Legacy releases, for a short period of time.  There are plenty of people
> (if my webusage logs don't lie) that want this exact thing, and I'm more
> than happy to service them.  I cannot however service people properly
> that want something else out of the project.

I added similar text as a new FAQ entry on the web site.  Feel free to
comment on it, etc.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Fri Mar  4 20:04:18 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Fri,  4 Mar 2005 14:04:18 -0600
Subject: how to get started with helping the project [...]
In-Reply-To: <1109873065.11173.59.camel@blue>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue> <1109871969.8226.4.camel@mdlinux>
	<1109873065.11173.59.camel@blue>
Message-ID: <1109966658.2d8f6d3a17b27@mail.ph.utexas.edu>

Quoting Jim Popovitch <jimpop at yahoo.com>:

> On Thu, 2005-03-03 at 12:46 -0500, Marc Deslauriers wrote:
> > I think if more rigorous guidelines and procedures are what you're
> > looking for, clearly FL is not adequate for your needs and you should be
> > looking elsewhere.
> 
> Is that the image/statement that FL really truly believes in?  If so,
> put it up on the main page of the website.

I refuse to put on the web page "Fedora Legacy does not meet the needs
of Jim Popovitch."

> > Who tests Debian's kernels?
> 
> A pretty well organized community.  Debian.org lists who does what, and
> who is responsible for what.  There is clearly a defined and easily
> identifiable process there.

Debian's community is very large.  Fedora Legacy's community will probably
never be large, due to what function it performs.  I don't think Fedora
Legacy could support a large number of offices and officers like Debian
does.

Having said that, it would be great if we made a list of other "positions"
we'd like to see filled, and get some volunteers to fill them.  Some that
come to mind are:

* Press Contact (or Public Relations)
* Documentation Writer (or Technical Writer)
* Key-Ring Manager (or Key Co-ordinator)
* Mirror Co-ordinator
* Accountant (or Donation Manager, etc)

Right now, the only defined/filled positions we have are:

* Leader (Jesse)
* Package Releasers (Marc, Dominic, Jesse)
* Webmaster (Eric)
* Community (all the rest of you great folks!)

If anyone can think of other positions, please share (via the mailing list).

> > This is a community effort,
> 
> No it's not.  It's what 4 people, maybe 5 that really do stuff?

First off, why can't 4 or 5 people be a community?

Second, I think your statement is a slap in the face to all the other
people who have contributed to the project.

It *IS* a community project, just the community, at this time, is small.

> Shouldn't there be more?  If there is to be more, there needs to be more
> structure and a better documented process, along with accountability.

I think we have tried to document the process as best as we can with the
limited amount of time and people involved.  I think we have fine
accountability.  Yes, we need more people, but we are growing (slowly),
and will no doubt continue to grow as time goes on.

> > if you want more extensive testing, you'll have to do it yourself
> > using your own set of guidelines and procedures.
> 
> Put that on the main website too.

Seems obvious, so I'm not sure it needs to be documented.  For example, it is
true of RHEL and Solaris and Windows, but I doubt you will find it on
the web sites for Red Hat, Sun, or Microsoft.  It is simply assumed.  They
(Red Hat, Sun, Microsoft, Fedora Legacy) do some good faith testing to
try to make sure the product works.  It is up to you (the consumer) to do
additional testing to make sure it works for you and meets your requirements
*before* you put it into production or use.  Remember, no one can test
all possible combinations...

> -Jim P.

-- 
Eric Rostetter



From pekkas at netcore.fi  Fri Mar  4 20:18:35 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Fri, 4 Mar 2005 22:18:35 +0200 (EET)
Subject: Speaking of contributions...
Message-ID: <Pine.LNX.4.61.0503042214430.11031@netcore.fi>

... there's a long list of packages which need very trivial install 
and "it seems to work" testing, under of "Packages in state RESOLVED":

http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt

In particular, I note openmotif, sharutils, ruby, ethereal, and php as 
ones which require only someone with FC1 to give it a "go ahead". 
Packages for RHL73 and RHL9 have been stalled due to this.

Or it that there just aren't enough people anymore who would care 
about FC1 (i.e., have already gone up to FC3 or something else)?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From ad+lists at uni-x.org  Fri Mar  4 20:21:02 2005
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Fri, 04 Mar 2005 21:21:02 +0100
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <pan.2005.03.04.16.56.35.789396@adelphia.net>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109873341.9846.447.camel@serendipity.dogma.lan>
	<pan.2005.03.03.19.43.46.910288@adelphia.net>
	<1109880833.9846.457.camel@serendipity.dogma.lan>
	<pan.2005.03.04.16.56.35.789396@adelphia.net>
Message-ID: <1109967662.9846.511.camel@serendipity.dogma.lan>

Am Fr, den 04.03.2005 schrieb beartooth um 17:56:

> Is this ok [y/N]: y
> warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 8df56d05
> Error: Could not find the GPG Key necessary to validate pkg
> /var/cache/yum/fedora-stable/packages/perl-DateManip-5.42-0.fdr.2.a.1.noarch.rpm
> Error: You may want to run yum clean or remove the file:
>  /var/cache/yum/fedora-stable/packages/perl-DateManip-5.42-0.fdr.2.a.1.noarch.rpm
> Error: You may also check that you have the correct GPG keys installed
> [root at localhost root]#
>                          =====

This is

http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/perl-DateManip-5.42-0.fdr.2.a.1.noarch.rpm

from fedora.us. Which is a very different repository and uses its own
GPG key.

rpm --import http://www.fedora.us/FEDORA-GPG-KEY

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.14_FC2smp 
Serendipity 21:18:50 up 11 days, 8:27, load average: 0.56, 0.39, 0.30 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050304/7acee779/attachment.sig>

From jimpop at yahoo.com  Fri Mar  4 20:25:39 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Fri, 04 Mar 2005 15:25:39 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <1109966658.2d8f6d3a17b27@mail.ph.utexas.edu>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue> <1109871969.8226.4.camel@mdlinux>
	<1109873065.11173.59.camel@blue>
	<1109966658.2d8f6d3a17b27@mail.ph.utexas.edu>
Message-ID: <1109967939.4675.4.camel@blue>

On Fri, 2005-03-04 at 14:04 -0600, Eric Rostetter wrote:
> Quoting Jim Popovitch <jimpop at yahoo.com>:
> 
> > On Thu, 2005-03-03 at 12:46 -0500, Marc Deslauriers wrote:
> > > I think if more rigorous guidelines and procedures are what you're
> > > looking for, clearly FL is not adequate for your needs and you should be
> > > looking elsewhere.
> > 
> > Is that the image/statement that FL really truly believes in?  If so,
> > put it up on the main page of the website.
> 
> I refuse to put on the web page "Fedora Legacy does not meet the needs
> of Jim Popovitch."

LOL!  For the most part FL does meet my needs.  In fact, the current
contributors do a LOT to assist people, like me, who need some prodding
and/or assistance as well.  What I want to do is find a way to improve
this and avoid any repetition in the release cycle so that updates are
pushed out faster than expected.

-Jim P.



From kelson at speed.net  Fri Mar  4 20:32:45 2005
From: kelson at speed.net (Kelson)
Date: Fri, 04 Mar 2005 12:32:45 -0800
Subject: how to get started with helping the project [...]
In-Reply-To: <1109956081.3339.9.camel@blue>
References: <421E9E0E.1030000@videotron.ca>	<200503031453.05137.guallar@easternrad.com>	<1109880271.13515.1.camel@blue>	<200503031518.53988.guallar@easternrad.com>	<1109882195.13515.21.camel@blue>
	<42277C85.506@securityspace.com>	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>	<1109944167.14766.21.camel@blue>	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>	<1109949032.14766.28.camel@blue>	<1109949366.13843.17.camel@bizzaro.psych.nyu.edu>	<1109949712.14766.34.camel@blue>
	<42288B6D.7010305@comcast.net> <1109956081.3339.9.camel@blue>
Message-ID: <4228C5ED.2000308@speed.net>

Jim Popovitch wrote:
> On Fri, 2005-03-04 at 11:23 -0500, David Curry wrote:
>>I find no basis in fact for your assertions that FL misleads people.  
>>Had I been on the receiving end of many of your remarks, I would have 
>>invited you to stuff your opinions where the sun don't shine.
> 
> :-)  I don't aim to make friends, only results.

I believe a parable about flies, honey, and vinegar might be in order here.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>



From rostetter at mail.utexas.edu  Fri Mar  4 20:40:50 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Fri,  4 Mar 2005 14:40:50 -0600
Subject: how to get started with helping the project [...]
In-Reply-To: <1109966658.2d8f6d3a17b27@mail.ph.utexas.edu>
References: <421E9E0E.1030000@videotron.ca> <1109783284.7291.29.camel@blue>
	<1109783825.904.119.camel@jkeating2.hq.pogolinux.com>
	<1109785665.7291.45.camel@blue>
	<1109788170.904.129.camel@jkeating2.hq.pogolinux.com>
	<1109788537.8998.6.camel@blue>
	<1109789168.904.139.camel@jkeating2.hq.pogolinux.com>
	<1109790506.9243.5.camel@blue>
	<1109793903.904.157.camel@jkeating2.hq.pogolinux.com>
	<1109795691.9243.31.camel@blue>
	<1109797844.904.171.camel@jkeating2.hq.pogolinux.com>
	<1109805924.4e87054ef8512@mail.ph.utexas.edu>
	<1109806985.904.202.camel@jkeating2.hq.pogolinux.com>
	<1109812427.10353.7.camel@blue>
	<Pine.LNX.4.61.0503030757380.21221@netcore.fi>
	<1109856553.11173.15.camel@blue> <1109871969.8226.4.camel@mdlinux>
	<1109873065.11173.59.camel@blue>
	<1109966658.2d8f6d3a17b27@mail.ph.utexas.edu>
Message-ID: <1109968850.01e9e6b54b909@mail.ph.utexas.edu>

Quoting Eric Rostetter <rostetter at mail.utexas.edu>:

> Having said that, it would be great if we made a list of other "positions"
> we'd like to see filled, and get some volunteers to fill them.  Some that
> come to mind are:

I've added the current list (as I've come up with it) to the "Participation"
page.  Comments, additions, etc. welcome.
 
> * Press Contact (or Public Relations)
> * Documentation Writer (or Technical Writer)
> * Key-Ring Manager (or Key Co-ordinator)
> * Mirror Co-ordinator
> * Accountant (or Donation Manager, etc)
> 
> Right now, the only defined/filled positions we have are:
> 
> * Leader (Jesse)
> * Package Releasers (Marc, Dominic, Jesse)
> * Webmaster (Eric)
> * Community (all the rest of you great folks!)
> 
> If anyone can think of other positions, please share (via the mailing list).

-- 
Eric Rostetter



From jimpop at yahoo.com  Fri Mar  4 20:40:45 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Fri, 04 Mar 2005 15:40:45 -0500
Subject: how to get started with helping the project [...]
In-Reply-To: <4228C5ED.2000308@speed.net>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue> <42277C85.506@securityspace.com>
	<1109893149.5963.69.camel@bizzaro.psych.nyu.edu>
	<1109913001.f6e9b407db7a7@mail.ph.utexas.edu>
	<1109944167.14766.21.camel@blue>
	<1109948061.d894dc9b9686d@mail.ph.utexas.edu>
	<1109949032.14766.28.camel@blue>
	<1109949366.13843.17.camel@bizzaro.psych.nyu.edu>
	<1109949712.14766.34.camel@blue> <42288B6D.7010305@comcast.net>
	<1109956081.3339.9.camel@blue>  <4228C5ED.2000308@speed.net>
Message-ID: <1109968845.4675.10.camel@blue>

On Fri, 2005-03-04 at 12:32 -0800, Kelson wrote:
> Jim Popovitch wrote:
> > On Fri, 2005-03-04 at 11:23 -0500, David Curry wrote:
> >>I find no basis in fact for your assertions that FL misleads people.  
> >>Had I been on the receiving end of many of your remarks, I would have 
> >>invited you to stuff your opinions where the sun don't shine.
> > 
> > :-)  I don't aim to make friends, only results.
> 
> I believe a parable about flies, honey, and vinegar might be in order here.

Sometimes the bitter taste of vinegar makes people think more than they
would with a belly full of honey.

-Jim P.



From bedouglas at earthlink.net  Fri Mar  4 20:46:26 2005
From: bedouglas at earthlink.net (bruce)
Date: Fri, 4 Mar 2005 12:46:26 -0800
Subject: using yum to upgrade from rh8 to fedora core 2
Message-ID: <012a01c520fb$3ce94d90$0301a8c0@Mesa.com>

hi

i have a few rh8 servers that i access remotely. i need to know what's the
best way to use yum to upgrade the systems to fedora (1 or 2). i've seen
bits of information/sites on the net that lead me to believe it can be done.
however, i'm not exactly sure what's the right procedure.

can someone give me pointers, or a site that i can get to that will provide
seriously basic steps as to the correct process.

i'm running
 httpd
 mysql
 gnome
 vncserver
 nfs
 etc...

and i don't want to screw up the current apps being run on the servers..

thanks

bruce



From madlists at teaparty.net  Fri Mar  4 20:47:07 2005
From: madlists at teaparty.net (Tom Yates)
Date: Fri, 4 Mar 2005 20:47:07 +0000 (GMT)
Subject: Speaking of contributions...
In-Reply-To: <Pine.LNX.4.61.0503042214430.11031@netcore.fi>
References: <Pine.LNX.4.61.0503042214430.11031@netcore.fi>
Message-ID: <Pine.LNX.4.61.0503042041020.14497@risby.gatekeeper.ltd.uk>

On Fri, 4 Mar 2005, Pekka Savola wrote:

> ... there's a long list of packages which need very trivial install and "it 
> seems to work" testing, under of "Packages in state RESOLVED":
>
> http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt

personally, i miss dom's periodic round-up mails.  yes, i know i can get 
exactly the same thing on the web, but whenever it came around i made a 
point of seeing if there was anything i could work on, and when i yum'ed a 
-testing package onto my server, i went straight to the roundup to find 
the bugzilla page to log my +VERIFY.

dom, is there any chance you'd consider posting these regularly?

> In particular, I note openmotif, sharutils, ruby, ethereal, and php as ones 
> which require only someone with FC1 to give it a "go ahead". Packages for 
> RHL73 and RHL9 have been stalled due to this.

is it worth starting discussion about separate releases, particularly as 
we move towards inheriting FC2?  i can see the advantages of pushing out, 
say, php fixes for all platforms at once, but i'm not sure they outweigh 
the problems caused by the extended wait for the +VERIFYs for the unloved 
distributions.

or are we having enough acrimonious discussions already?


-- 

   Tom Yates
   Cambridge, UK.



From michal at harddata.com  Fri Mar  4 21:27:06 2005
From: michal at harddata.com (Michal Jaegermann)
Date: Fri, 4 Mar 2005 14:27:06 -0700
Subject: using yum to upgrade from rh8 to fedora core 2
In-Reply-To: <012a01c520fb$3ce94d90$0301a8c0@Mesa.com>;
	from bedouglas@earthlink.net on Fri, Mar 04, 2005 at 12:46:26PM
	-0800
References: <012a01c520fb$3ce94d90$0301a8c0@Mesa.com>
Message-ID: <20050304142706.B22145@mail.harddata.com>

On Fri, Mar 04, 2005 at 12:46:26PM -0800, bruce wrote:
> 
> i have a few rh8 servers that i access remotely. i need to know what's the
> best way to use yum to upgrade the systems to fedora (1 or 2).

I would skip FC1 if only possible.

Your biggest hurdle is to get a system to a state where is enough of
updates for it to be still bootable and a networking in a working
state after a reboot.  The rest can be done, step by step if needed,
from there.  I have no idea if this is really possible but I have,
written in C, applications from times of RH7.x distros still working
happily on FC3 so there is a good chance that this will indeed work.

I would think that after pointing yum to relevant depositories doing

    yum update yum

or maybe

    yum update yum kernel

would get you through the first hump as you will get much more
than it seems due to dependency resolution.  After a reboot

    yum upgrade

should do the rest.  I would definitely try that first on some
"scratch" system to which I have a local access.

Thinking about it Python may give a trouble here because
yum is written it it.  So maybe you need two versions installed
in different paths so yum will not start freak out once you
replaced these?  If you have both you may tell yum what to
use depending on in which stage you are.  Or maybe this will
not happen or can be easily worked around with one or two
'rpm -Fvh ...'?  No idea really but there could be some delicate
points with ordering.  No substitution for trying.

> 
> i'm running
>  httpd
>  mysql
>  gnome
>  vncserver
>  nfs
>  etc...
> 
> and i don't want to screw up the current apps being run on the servers..

Well, you expect to run updated versions of all that stuff.  In case
of C++ written applications that most likely would be a hard
requirement.

   Michal



From hbo at egbok.com  Fri Mar  4 22:41:58 2005
From: hbo at egbok.com (Howard Owen)
Date: Fri, 04 Mar 2005 14:41:58 -0800
Subject: Call for help
In-Reply-To: <1109879036.12887.2.camel@jkeating2.hq.pogolinux.com>
References: <1109874017.4902.56.camel@localhost.localdomain>
	<20050303182825.GV14494@debian-server.aei.mpg.de>
	<1109879036.12887.2.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1109976118.9337.69.camel@Quirk.egbok.com>

The challenging thing was getting all the content in a usable form. The
Wiki is riddled with SPAM links that point at action=create links on the
twiki itself. Since wget is drain bamaged in that it first downloads the
link, *then* decides whether it should have done so or not, it slowed
things down considerably. It would probably be easier in the future to
have access to a tarball of the site's contents made on the server.

I proned the pages I received so that I only scanned the latest versions
of the various twiki pages. I then ran 

   grep -R -H -o -n -i fedora.us * >../FL_references_to_fedora_us.txt

>From the top of the downloaded tree. The results look like this:

	wiki/index.php/UpdatedOverview:112:fedora.us
	wiki/index.php/UpdatedOverview:113:fedora.us
	fedora.us
	wiki/index.php/UpdatedOverview:114:fedora.us
	wiki/index.php/QaTesting:79:fedora.us
	wiki/index.php/QaTesting:95:fedora.us

And so forth. The output is available at
http://egbok.com/FL_references_to_fedora_us.txt



On Thu, 2005-03-03 at 11:43 -0800, Jesse Keating wrote:
> On Thu, 2005-03-03 at 19:28 +0100, Steffen Grunewald wrote:
> > What about using wget to create a working copy of the wiki contents,
> > then recursive grep through it?
> 
> However you want to accumulate a list is fine with me (:
> 

--
Howard Owen       RHCE, BMOC, GP "Even if you are on the right
EGBOK Consultants Linux Architect track, you'll get run over if you
hbo at egbok.com     +1-650-218-2216 just sit there." - Will Rogers



From pizza at shaftnet.org  Fri Mar  4 23:32:14 2005
From: pizza at shaftnet.org (Stuffed Crust)
Date: Fri, 4 Mar 2005 18:32:14 -0500
Subject: Speaking of contributions...
In-Reply-To: <Pine.LNX.4.61.0503042214430.11031@netcore.fi>
References: <Pine.LNX.4.61.0503042214430.11031@netcore.fi>
Message-ID: <20050304233214.GA22602@shaftnet.org>

On Fri, Mar 04, 2005 at 10:18:35PM +0200, Pekka Savola wrote:
> http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt

These I know to WorkForMe(tm), running on production systems.  Nobody's 
complained about something being broken yet.  :)

FC1: mailman-2.1.5-8.legacy  
FC1: php-4.3.10-1.1.legacy
FC1: sharutils-4.2.1-17.2.legacy
RH9: mysql-3.23.58-1.90.5.legacy
RH9: nfs-utils-1.0.1-3.9.1.legacy
RH9: php-4.2.2-17.10.legacy
RH9: kernel-2.4.20-42.9.legacy (i686 SMP)

sharutils I've only used to unshar files, and it's worked.  

I guess I could create an account on bugzilla..

 - Solomon
-- 
Solomon Peachy        				 ICQ: 1318344
Melbourne, FL 					 JID: pitha at myjabber.net
Quidquid latine dictum sit, altum viditur
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050304/cc8cb17a/attachment.sig>

From jkeating at j2solutions.net  Sat Mar  5 00:43:54 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 04 Mar 2005 16:43:54 -0800
Subject: Speaking of contributions...
In-Reply-To: <20050304233214.GA22602@shaftnet.org>
References: <Pine.LNX.4.61.0503042214430.11031@netcore.fi>
	<20050304233214.GA22602@shaftnet.org>
Message-ID: <1109983434.12887.67.camel@jkeating2.hq.pogolinux.com>

On Fri, 2005-03-04 at 18:32 -0500, Stuffed Crust wrote:
> I guess I could create an account on bugzilla..

That would be helpful!  (:

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From bedouglas at earthlink.net  Sat Mar  5 04:01:49 2005
From: bedouglas at earthlink.net (bruce)
Date: Fri, 4 Mar 2005 20:01:49 -0800
Subject: upgrading redhat from 8.0 -> fedora core 3
Message-ID: <018001c52138$0f90cc00$0301a8c0@Mesa.com>

hi,

i want to upgrade a redhat 8.0 to fedora core 3, using yum.

as i understand the process, i need to get the yum for the fedora core 3.
(is this correct?)

i should:

su - root

rpm --import http://fedora.redhat.com/about/security/4F2A6FD2.txt

http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/RPM
S/yum-2.1.11-3.noarch.rpm

http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/RPM
S/fedora-release-3-8.i386.rpm

rpm -Uvh --force fedora-release*.rpm
rpm -Uvh --force yum-2.1.11*.rpm

yum upgrade yum python rpm-python rpm glibc glibc-common \
                redhat-config-\* XFree86\* libxml2\*

//yum upgrade rpm python yum

update the /etc/yum.conf file with the following:

[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=fedora-release
tolerant=1
exactarch=0
# Added this because some mirrors go down and then retying takes forever.
retries=1
timeout=10

# Basic Repos are in /etc/yum.conf.d/ #

###################
## Fedora Extras ##
###################

[extras]
name=Fedora Extras - $releasever - $basearch
baseurl=http://fr2.rpmfind.net/linux/fedora/extras/$releasever/$basearch/
  http://mirrors.kernel.org/fedora/extras/$releasever/$basearch/
  http://mirror.hiwaay.net/redhat/fedora/linux/extras/$releasever/$basearch/

http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/lin
ux/extras/$releasever/$basearch/
#
http://download.fedora.redhat.com/pub/fedora/linux/extras/$releasever/$basea
rch/
gpgcheck=0
gpgkey=http://download.fedora.redhat.com/pub/fedora/linux/extras/RPM-GPG-KEY
-Fedora-Extras

###############
## Livna.org ##
###############

[livna-stable]
name=Livna.org - Fedora Compatible Packages (stable)
baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.stable
  http://livna.cat.pdx.edu/fedora/$releasever/$basearch/RPMS.stable
#gpgcheck=1


if i understand everything, i should be at a point where i can do:

yum upgrade

which should then begin the process of upgrading everything from redhat 8 to
fedora core 3.

have i missed anything????

thanks
-bruce



From marcdeslauriers at videotron.ca  Sat Mar  5 14:54:11 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sat, 05 Mar 2005 09:54:11 -0500
Subject: Fedora Legacy Test Update Notification: spamassassin
Message-ID: <4229C813.5040003@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2268
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2268
2005-03-05
---------------------------------------------------------------------

Name        : spamassassin
Versions    : fc1: spamassassin-2.63-0.2.1.legacy
Summary     : Spam filter for email which can be invoked from mail
               delivery agents.
Description :
SpamAssassin provides you with a way to reduce if not completely
eliminate Unsolicited Commercial Email (SPAM) from your incoming email.
It can be invoked by a MDA such as sendmail or postfix, or can be called
from a procmail script, .forward file, etc.  It uses a genetic-algorithm
evolved scoring system to identify messages which look spammy, then
adds headers to the message so they can be filtered by the user's mail
reading software.  This distribution includes the spamd/spamc components
which create a server that considerably speeds processing of mail.

---------------------------------------------------------------------
Update Information:

An updated spamassassin package that fixes a denial of service bug when
parsing malformed messages is now available.

SpamAssassin provides a way to reduce unsolicited commercial email
(SPAM) from incoming email.

A denial of service bug has been found in SpamAssassin versions below
2.64. A malicious attacker could construct a message in such a way that
would cause spamassassin to stop responding, potentially preventing the
delivery or filtering of email. The Common Vulnerabilities and Exposures
project (cve.mitre.org) has assigned the name CAN-2004-0796 to this
issue.

Users of SpamAssassin should update to these updated packages which
contain a backported patch and is not vulnerable to this issue.

---------------------------------------------------------------------
Changelogs

fc1:
* Tue Nov 16 2004 Rob Myers <rob.myers at gtri.gatech.edu> 2.63-0.2.1.legacy
- patch for CAN-2004-0796 (FL #2268)

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

fc1:
0a34a50cec6fb1e4d4359d49e928adc8aba06048 
fedora/1/updates-testing/i386/spamassassin-2.63-0.2.1.legacy.i386.rpm
e4b75ec1d65a4d32cd80e55b5fb720aa73bdc4f5 
fedora/1/updates-testing/SRPMS/spamassassin-2.63-0.2.1.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050305/8484a763/attachment.sig>

From marcdeslauriers at videotron.ca  Sat Mar  5 14:54:39 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sat, 05 Mar 2005 09:54:39 -0500
Subject: Fedora Legacy Test Update Notification: dhcp
Message-ID: <4229C82F.9010002@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2251
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2251
2005-03-05
---------------------------------------------------------------------

Name        : dhcp
Versions    : rh7.3:
Summary     : A DHCP (Dynamic Host Configuration Protocol) server and
               relay agent.
Description :
DHCP (Dynamic Host Configuration Protocol) is a protocol which allows
individual devices on an IP network to get their own network
configuration information (IP address, subnetmask, broadcast address,
etc.) from a DHCP server. The overall purpose of DHCP is to make it
easier to administer a large network. The dhcp package includes the
DHCP server and a DHCP relay agent.

---------------------------------------------------------------------
Update Information:

Updated dhcp packages that fix a security issue are now available.

Xpdf is a DHCP (Dynamic Host Configuration Protocol) server and
relay agent.

"infamous41md" noticed that the log functions in dhcp 2.x pass
parameters to a function that uses format strings. One use seems to be
exploitable in connection with a malicious DNS server. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-1006 to this issue.

Users of dhcp are advised to upgrade to this errata package, which
contains backported patches correcting this issue.

---------------------------------------------------------------------
Changelogs

rh73:
* Fri Mar 04 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
1:2.0pl5-8.2.legacy
- Added missing groff BuildRequires

* Sun Dec 19 2004 Pekka Savola <pekkas at netcore.fi> 1:2.0pl5-8.1.legacy
- add ftp://ftp.isc.org/isc/dhcp/dhcp-2.0-history/dhcp-2.0pl6.patch to
   fix CAN-2004-1006

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
e134b4118edc63c20b1227d3b199edf55e9c6411 
redhat/7.3/updates-testing/i386/dhcp-2.0pl5-8.2.legacy.i386.rpm
873fe4bb121b857436cc044cf379597f78bc0e4b 
redhat/7.3/updates-testing/SRPMS/dhcp-2.0pl5-8.2.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050305/8df24086/attachment.sig>

From marcdeslauriers at videotron.ca  Sat Mar  5 14:55:05 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sat, 05 Mar 2005 09:55:05 -0500
Subject: Fedora Legacy Test Update Notification: pam
Message-ID: <4229C849.3020805@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2010
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2010
2005-03-05
---------------------------------------------------------------------

Name        : pam
Versions    : rh7.3: pam-0.75-46.10.legacy
Versions    : rh9: pam-0.75-62.10.legacy
Summary     : A security tool which provides authentication for
               applications.
Description :
PAM (Pluggable Authentication Modules) is a system security tool that
allows system administrators to set authentication policy without
having to recompile programs that handle authentication.

---------------------------------------------------------------------
Update Information:

Updated pam packages that fix a security vulnerability are now
available.

PAM (Pluggable Authentication Modules) is a system security tool that
allows system administrators to set an authentication policy without
having to recompile programs that handle authentication.

These updates fix a potential security problem present in the pam_wheel
module. These updates correct a bug in the pam_lastlog module which
prevented it from properly manipulating the /var/log/lastlog entry for
users with very high user IDs.

The pam_wheel module is used to restrict access to a particular service
based on group membership. If the pam_wheel module was used with the
"trust" option enabled, but without the "use_uid" option, any local user
would be able to spoof the username returned by getlogin(). The user
could therefore gain access to a superuser account without supplying a
password. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2003-0388 to this issue.

When manipulating the entry in /var/log/lastlog, which corresponds to a
given user, the pam_lastlog module calculates the location of the entry
by multiplying the UID and the length of an entry in the file. On some
systems, the result of this calculation would mistakenly be truncated to
32 bits for users with sufficiently high UIDs.

All users of pam should upgrade to these updated packages, which resolve
these issues.

---------------------------------------------------------------------
Changelogs

rh73:
* Sat Mar 05 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
0.75-46.10.legacy.7x
- Added linuxdoc-tools and tetex-dvips to BuildPrereq

* Thu Sep 02 2004 Dave Bostch <dwb7 at ccmr.cornell.edu>
- Added flex to BuildPrereq

* Tue Aug 31 2004 Dave Botsch <dwb7 at ccmr.cornell.edu>
- Added legacy keyword

rh9:
* Sat Mar 05 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
0.75-62.10.legacy
- Added missing flex, linuxdoc-tools and tetex-dvips BuildPrereq

* Sat Feb 26 2005 Pekka Savola <pekkas at netcore.fi> 0.75-62.9.legacy
- rebuild for Fedora Legacy to fix CAN-2003-0388 and minor bugs (#2010)

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
bb7b9e1c63be2eb2064b46eacaf8d0ce68594d11 
redhat/7.3/updates-testing/i386/pam-0.75-46.10.legacy.7x.i386.rpm
9af62c26654ba14bde7bf6e3b59b9b4f62fd5d35 
redhat/7.3/updates-testing/i386/pam-devel-0.75-46.10.legacy.7x.i386.rpm
8f06c0d3a0cb5938206c4d2d20484f325ebcca42 
redhat/7.3/updates-testing/SRPMS/pam-0.75-46.10.legacy.7x.src.rpm

rh9:
622eac1455b5ccb0cf75705cc0f42b3226f9cc31 
redhat/9/updates-testing/i386/pam-0.75-62.10.legacy.i386.rpm
18c330ff1ef063f21a3b3c8eb297d09bb004ee67 
redhat/9/updates-testing/i386/pam-devel-0.75-62.10.legacy.i386.rpm
8c10c919199f35e5ef785b57f35a8d300d3ea01e 
redhat/9/updates-testing/SRPMS/pam-0.75-62.10.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050305/a36ee417/attachment.sig>

From marcdeslauriers at videotron.ca  Sat Mar  5 18:10:39 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sat, 05 Mar 2005 13:10:39 -0500
Subject: Fedora Legacy Test Update Notification: gd
Message-ID: <4229F61F.1000103@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2254
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2254
2005-03-05
---------------------------------------------------------------------

Name        : gd
Versions    : rh7.3: gd-1.8.4-4.1.legacy
Versions    : rh9: gd-1.8.4-11.1.legacy
Versions    : fc1: gd-2.0.15-1.2.legacy
Summary     : A graphics library for quick creation of PNG or JPEG
              images.
Description :
The gd graphics library allows your code to quickly draw images complete
with lines, arcs, text, multiple colors, cut and paste from other
images, and flood fills. The library will write out the result as a PNG
or JPEG file. This is particularly useful in Web applications, where PNG
and JPEG are two of the formats accepted for inline images by most
Web browsers. Note that gd is not a paint or graphics manipulation
program.

---------------------------------------------------------------------
Update Information:

Updated gd packages that fix security issues with overflow in various
memory allocation calls are now available.

The gd packages contain a graphics library used for the dynamic creation
of images such as PNG and JPEG.

Several buffer overflows were reported in various memory allocation
calls. An attacker could create a carefully crafted image file in such a
way that it could cause ImageMagick to execute arbitrary code when
processing the image. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2004-0990 to these issues.

While researching the fixes to these overflows, additional buffer
overflows were discovered in calls to gdMalloc. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-0941 to these issues.

Users of gd should upgrade to these updated packages, which contain a
backported security patch, and are not vulnerable to these issues.

---------------------------------------------------------------------
Changelogs

rh73:
* Tue Dec 21 2004 Pekka Savola <pekkas at netcore.fi>: 1.8.4-4.1.legacy
- Fix CAN-2004-0941,CAN-2004-0990, from RHEL.

rh9:
* Tue Dec 21 2004 Pekka Savola <pekkas at netcore.fi>: 1.8.4-11.1.legacy
- Fix CAN-2004-0941,CAN-2004-0990, from RHEL.

fc1:
* Sat Mar 05 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
2.0.15-1.2.legacy
- Added missing XFree86-devel BuildPrereq

* Fri Mar 04 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
2.0.15-1.1.legacy
- Added security patch for CAN-2004-0941 and CAN-2004-0990

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
094e683de916db07104de9f735a0773db3a89d25 
redhat/7.3/updates-testing/i386/gd-1.8.4-4.1.legacy.i386.rpm
addb29d84db162ceedd78e208efa08b3f7b35589 
redhat/7.3/updates-testing/i386/gd-devel-1.8.4-4.1.legacy.i386.rpm
e736bda88bfdc20a5560c33a2866d36af57d365a 
redhat/7.3/updates-testing/i386/gd-progs-1.8.4-4.1.legacy.i386.rpm
f75168266e076834d3c8c4bd247f5b71dd46a6b3 
redhat/7.3/updates-testing/SRPMS/gd-1.8.4-4.1.legacy.src.rpm

rh9:
3315825ff28caf0516227aa9c7b60df6ad5fb865 
redhat/9/updates-testing/i386/gd-1.8.4-11.1.legacy.i386.rpm
e4e1128a446799ade2bdfd31c2b2165e8391298c 
redhat/9/updates-testing/i386/gd-devel-1.8.4-11.1.legacy.i386.rpm
68ddd0a5e252b8c478006a7121a516a125b468e7 
redhat/9/updates-testing/i386/gd-progs-1.8.4-11.1.legacy.i386.rpm
66a0ea816ea63de04c80914410cec6d772e89dee 
redhat/9/updates-testing/SRPMS/gd-1.8.4-11.1.legacy.src.rpm

fc1:
e468a13340eb0adc2c4a53ea46db6acd2a909cdc 
fedora/1/updates-testing/i386/gd-2.0.15-1.2.legacy.i386.rpm
1b589147f1a2779031d9815c330b919098fcc4ca 
fedora/1/updates-testing/i386/gd-devel-2.0.15-1.2.legacy.i386.rpm
eec3d79e1bb687c7aae118d561ff8683d0c4713d 
fedora/1/updates-testing/i386/gd-progs-2.0.15-1.2.legacy.i386.rpm
ca49d8c20730afd691e5cbe83b9c396a57a789aa 
fedora/1/updates-testing/SRPMS/gd-2.0.15-1.2.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050305/df0de234/attachment.sig>

From marcdeslauriers at videotron.ca  Sat Mar  5 18:11:54 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sat, 05 Mar 2005 13:11:54 -0500
Subject: Fedora Legacy Test Update Notification: shadow-utils
Message-ID: <4229F66A.8010603@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2253
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2253
2005-03-05
---------------------------------------------------------------------

Name        : shadow-utils
Versions    : rh7.3: shadow-utils-20000902-9.7.2.legacy
Versions    : rh9: shadow-utils-4.0.3-6.2.legacy
Versions    : fc1: shadow-utils-4.0.3-12.2.legacy
Summary     : Utilities for managing accounts and shadow password files.
Description :
The shadow-utils package includes the necessary programs for
converting UNIX password files to the shadow password format, plus
programs for managing user and group accounts. The pwconv command
converts passwords to the shadow password format. The pwunconv command
unconverts shadow passwords and generates an npasswd file (a standard
UNIX password file). The pwck command checks the integrity of password
and shadow files. The lastlog command prints out the last login times
for all users. The useradd, userdel, and usermod commands are used for
managing user accounts. The groupadd, groupdel, and groupmod commands
are used for managing group accounts.

---------------------------------------------------------------------
Update Information:

Updated shadow-utils packages that fix a minor security issue are now
available.

The shadow-utils package includes the necessary programs for converting
UNIX password files to the shadow password format, plus programs for
managing user and group accounts.

Martin Schulze has reported a vulnerability in shadow-utils, which can
be exploited by a local attacker to bypass certain security
restrictions. This could lead to unauthorized modification of account
information with an expired password. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2004-1001
to this issue.

Users of shadow-utils are advised to upgrade to these errata packages,
which contain a backported patch correcting this issue.

---------------------------------------------------------------------
Changelogs

rh73:
* Sat Mar 05 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
1:20000902-9.7.2.legacy
- added missing gettext BuilPrereq

* Mon Dec 20 2004 Pekka Savola <pekkas at netcore.fi> 1:20000902-9.7.1.legacy
- added patch to CAN-2004-1001 from Debian. (#2253)

rh9:
* Sat Mar 05 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
2:4.0.3-6.2.legacy
- added missing gettext to BuildPrereq

* Mon Dec 20 2004 Pekka Savola <pekkas at netcore.fi> 2:4.0.3-6.1.legacy
- added patch to CAN-2004-1001 from Debian. (#2253)

fc1:
* Sat Mar 05 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
2:4.0.3-12.2.legacy
- added missing gettext BuildPrereq

* Mon Dec 20 2004 Pekka Savola <pekkas at netcore.fi> 2:4.0.3-12.1.legacy
- added patch to CAN-2004-1001 from Debian. (#2253)

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
47ccff4950fc8e8571c9a5edd2b1d23e653d3697 
redhat/7.3/updates-testing/i386/shadow-utils-20000902-9.7.2.legacy.i386.rpm
1f7bb129dc2c1a68a0e50f284555bbfad869b53c 
redhat/7.3/updates-testing/SRPMS/shadow-utils-20000902-9.7.2.legacy.src.rpm

rh9:
eb87986f5946d96029a5e1f949c033910d1535f3 
redhat/9/updates-testing/i386/shadow-utils-4.0.3-6.2.legacy.i386.rpm
c0fe9a828f848514978546eb1014f2b8a2c7d65f 
redhat/9/updates-testing/SRPMS/shadow-utils-4.0.3-6.2.legacy.src.rpm

fc1:
4adc8e194bd9d04adcf52596b92a07d2dd33fc91 
fedora/1/updates-testing/i386/shadow-utils-4.0.3-12.2.legacy.i386.rpm
008ed1a1fec1020a435f9d95d0f61ebee59f17ae 
fedora/1/updates-testing/SRPMS/shadow-utils-4.0.3-12.2.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050305/d70d2880/attachment.sig>

From marcdeslauriers at videotron.ca  Sat Mar  5 18:12:19 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sat, 05 Mar 2005 13:12:19 -0500
Subject: Fedora Legacy Test Update Notification: libtiff
Message-ID: <4229F683.8030707@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2163
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2163
2005-03-05
---------------------------------------------------------------------

Name        : libtiff
Versions    : rh7.3: libtiff-3.5.7-2.2.legacy
Versions    : rh9: libtiff-3.5.7-11.2.legacy
Versions    : fc1: libtiff-3.5.7-14.2.legacy
Summary     : A library of functions for manipulating TIFF format image
               files.
Description :
The libtiff package contains a library of functions for manipulating
TIFF (Tagged Image File Format) image format files. TIFF is a widely
used file format for bitmapped images. TIFF files usually end in the
.tif extension and they are often quite large.

---------------------------------------------------------------------
Update Information:

Updated libtiff packages that fix various buffer and integer overflows
are now available.

The libtiff package contains a library of functions for manipulating
TIFF (Tagged Image File Format) image format files.

During a source code audit, Chris Evans discovered a number of integer
overflow bugs that affect libtiff. An attacker who has the ability to
trick a user into opening a malicious TIFF file could cause the
application linked to libtiff to crash or possibly execute arbitrary
code. The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the names CAN-2004-0886 and CAN-2004-0804 to these issues.

Additionally, a number of buffer overflow bugs that affect libtiff have
been found. An attacker who has the ability to trick a user into opening
a malicious TIFF file could cause the application linked to libtiff to
crash or possibly execute arbitrary code. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2004-0803 to
this issue.

iDEFENSE has reported an integer overflow bug that affects libtiff. An
attacker who has the ability to trick a user into opening a malicious
TIFF file could cause the application linked to libtiff to crash or
possibly execute arbitrary code. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2004-1308 to
this issue.

Dmitry V. Levin reported another integer overflow in the tiffdump
utility. An atacker who has the ability to trick a user into opening a
malicious TIFF file with tiffdump could possibly execute arbitrary code.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-1183 to this issue.

All users are advised to upgrade to these updated packages, which
contain backported fixes for these issues.

---------------------------------------------------------------------
Changelogs

rh73:
* Sat Feb 19 2005 Pekka Savola <pekkas at netcore.fi> 3.5.7-2.2.legacy
- Added security patches for CAN-2004-{1183,1308} from RHEL (#2163)

* Tue Oct 19 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
3.5.7-2.1.legacy
- Added security patches for CAN-2004-0803 and CAN-2004-0886

rh9:
* Sat Feb 19 2005 Pekka Savola <pekkas at netcore.fi> 3.5.7-11.2.legacy
- Added security patches for CAN-2004-{1183,1308} from RHEL (#2163)

* Tue Oct 19 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
3.5.7-11.1.legacy
- Added security patches for CAN-2004-0803 and CAN-2004-0886

fc1:
* Sat Feb 19 2005 Pekka Savola <pekkas at netcore.fi> 3.5.7-14.2.legacy
- Added security patches for CAN-2004-{1183,1308} from RHEL (#2163)

* Tue Oct 19 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
3.5.7-14.1.legacy
- Added security patches for CAN-2004-0803 and CAN-2004-0886

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
524fd6c80901dbd665cfbf0b4ba1eea276a95cca 
redhat/7.3/updates-testing/i386/libtiff-3.5.7-2.2.legacy.i386.rpm
3ced2ba5eac07c60515a41d73dbfb0df36cfc962 
redhat/7.3/updates-testing/i386/libtiff-devel-3.5.7-2.2.legacy.i386.rpm
864581d2f1d76fcc5d0540173338a84a7a3ffe80 
redhat/7.3/updates-testing/SRPMS/libtiff-3.5.7-2.2.legacy.src.rpm

rh9:
a17298a3be3e3d6f7fce2108ac226ff8ef26ee39 
redhat/9/updates-testing/i386/libtiff-3.5.7-11.2.legacy.i386.rpm
b35700b8e8ee819565998a033f484ebd7e837646 
redhat/9/updates-testing/i386/libtiff-devel-3.5.7-11.2.legacy.i386.rpm
2024a97a377a37851d3a4be92403eaad0a7b1be2 
redhat/9/updates-testing/SRPMS/libtiff-3.5.7-11.2.legacy.src.rpm

fc1:
8dd2d8035eaf4b0e41cc7ac68536b752387a1cc8 
fedora/1/updates-testing/i386/libtiff-3.5.7-14.2.legacy.i386.rpm
4475fb4f26ab358d1c9bf8b6e8da060eace1a8dd 
fedora/1/updates-testing/i386/libtiff-devel-3.5.7-14.2.legacy.i386.rpm
f854a97125ca806b9a1c04c985f9939c6b6f7611 
fedora/1/updates-testing/SRPMS/libtiff-3.5.7-14.2.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050305/f106f86e/attachment.sig>

From dr at cluenet.de  Sat Mar  5 18:25:37 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 5 Mar 2005 19:25:37 +0100
Subject: how to get started with helping the project [...]
In-Reply-To: <1109884466.12887.11.camel@jkeating2.hq.pogolinux.com>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
	<Pine.LNX.4.61.0503032246580.10083@netcore.fi>
	<20050303210630.GA4513@srv01.cluenet.de>
	<1109884466.12887.11.camel@jkeating2.hq.pogolinux.com>
Message-ID: <20050305182537.GA31049@srv01.cluenet.de>

On Thu, Mar 03, 2005 at 01:14:26PM -0800, Jesse Keating wrote:
> On Thu, 2005-03-03 at 22:06 +0100, Daniel Roesen wrote:
> > The problem is that people who take security serious can't wait weeks
> > and months for security fixes to arrive from FL. And as that's
> > (security
> > fixes) all FL provides...
> 
> This is very true.  It continues to be my main goal to get packages out
> quicker.

Excellent.

> One can say the same about distros like Red Hat and Debian, in
> that the time between a vuln being known and packages coming out may be
> too long for the really sensitive systems.

The old Red Hat was OK for me in almost all cases. Can't judge Debian.

> Although, these distros communicate about vulns using VendorSec in a
> non-public way, and are able to coordinate the announcement of and
> therefor the release of packages. Fedora Legacy is part of VendorSec
> now, however to really act on any information I get from there, I
> would need to close community access to the bug and communicate
> privately with a very very select few about the issue. I'm torn on
> this.  It would allow for potentially faster and more coordinated
> packages, but the community would have a lot less chance to do the QA
> and testing.  It is a very hard thing to do.

I fully understand this problem and am happy that we are "in sync" about
it.

> What may happen is that we'll have testing packages ready at coordinated
> announce time, for the community to QA so that we can release shortly
> thereafter.  Is anybody opposed to this strategy?  It will still mean
> private bugs in bugzilla until ready for announcement.

I think that is the only sane strategy for Fedora Legacy in order to
support security-concicious (and not only "enterprise customers" are,
but I'm so for all my private systems, all connected to the Internet)
folks.

There are two general types of disclosure: coordinated (vendor-sec etc.)
disclosure (CD) and uncoordinated disclosure (UD).

There should be a small team (the "very very select few" you mentioned)
which then prepares packages, to be released for testing at coordinated
disclosure time (CDT). When CDT has come, FL releases advisory to the
usual channels (Bugtraq, FL-announce) and releases the prepared packages
for testing. When at CDT+3days no showstoppers have appeared, the
packages are declared fully released. So people can judge for themselves
(only THEY know THEIR risk level and exposure) wether they go quickly
with the test packages, or wait for the CDT+3days "they are OK"
declaration.

Same procedure for UD, but a different team can handle those, package
test packages ASAP, and release into testing. After 3 days and no
showstoppers, packages are declared "fully released".

If any problems with packages appear, new packages are prepared and made
available.

The "3 days" is more or less an arbitrary number and may be larger.

Baseline idea: get packages out as quickly as possible, even if that may
cause problems. Installing stuff by hand has much bigger chance of hosing
something, and is more difficult to revert again. So FL would already
provide an added value also to folks who want/need to upgrade ASAP.

And from what I'm seeing, the chance that updates really break something
REALLY badly is quite low.

I'm not sure how many vulns are preannounced on vendor-sec nowadays,
but I guess splitting work a little between two teams of people on
vendor-sec and people working on non-coord disclosure issues can also
distribute some load.

> > For me, FL is only of value if I can save time by just installing FL
> > RPMs instead of rolling my own security updates. But at least remotely
> > exploitable vulnerabilities require *immediate* fix so people can't
> > wait weeks and months for FL to get into gear. So one has to backport
> > or install newer, fixed versions manually. So no time saved at all.
> 
> Right.  THere are those that don't rely on the vendor at all for
> security fixes, they do it themselves using source on the critical
> systems.  There is no way to compete with the speed this can have.

Not to the extreme, but quite close, especially in the coordinated
disclosure scenario. And with "immediate" does (in this context, for me)
mean more like "within next 24-48 hours", not "within next 30 minutes".
:-)


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From dr at cluenet.de  Sat Mar  5 18:27:44 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 5 Mar 2005 19:27:44 +0100
Subject: how to get started with helping the project [...]
In-Reply-To: <1109911255.0b912eb713be4@mail.ph.utexas.edu>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
	<Pine.LNX.4.61.0503032246580.10083@netcore.fi>
	<20050303210630.GA4513@srv01.cluenet.de>
	<1109884466.12887.11.camel@jkeating2.hq.pogolinux.com>
	<1109911255.0b912eb713be4@mail.ph.utexas.edu>
Message-ID: <20050305182744.GB31049@srv01.cluenet.de>

On Thu, Mar 03, 2005 at 10:40:55PM -0600, Eric Rostetter wrote:
> > > For me, FL is only of value if I can save time by just installing FL
> > > RPMs instead of rolling my own security updates. But at least remotely
> > > exploitable vulnerabilities require *immediate* fix so people can't
> > > wait
> > > weeks and months for FL to get into gear. So one has to backport or
> > > install newer, fixed versions manually. So no time saved at all.
> 
> Or buy a pay service such a that from Progeny.

Nowadays I'm administering only my private machines, so... :-) But I do
take "keeping them secure" as important as with any commercial
production system... :-)


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From jkeating at j2solutions.net  Sat Mar  5 20:28:46 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 05 Mar 2005 12:28:46 -0800
Subject: how to get started with helping the project [...]
In-Reply-To: <20050305182537.GA31049@srv01.cluenet.de>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
	<Pine.LNX.4.61.0503032246580.10083@netcore.fi>
	<20050303210630.GA4513@srv01.cluenet.de>
	<1109884466.12887.11.camel@jkeating2.hq.pogolinux.com>
	<20050305182537.GA31049@srv01.cluenet.de>
Message-ID: <1110054526.4902.80.camel@localhost.localdomain>

On Sat, 2005-03-05 at 19:25 +0100, Daniel Roesen wrote:
> There should be a small team (the "very very select few" you
> mentioned)
> which then prepares packages, to be released for testing at
> coordinated
> disclosure time (CDT). When CDT has come, FL releases advisory to the
> usual channels (Bugtraq, FL-announce) and releases the prepared
> packages
> for testing. When at CDT+3days no showstoppers have appeared, the
> packages are declared fully released. So people can judge for
> themselves
> (only THEY know THEIR risk level and exposure) wether they go quickly
> with the test packages, or wait for the CDT+3days "they are OK"
> declaration.

This idea is good, and goes along w/ my thoughts except for a couple
things.

1) we can't announce testing packages to Bugtraq, and I'd rather not do
it to Fedora Legacy Announce either.  These are reserved for released
packages.  But we will announce to Fedora Legacy List when we have a new
package for testing, just as we do now.

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050305/c8ea5a26/attachment.sig>

From dr at cluenet.de  Sat Mar  5 20:47:47 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sat, 5 Mar 2005 21:47:47 +0100
Subject: how to get started with helping the project [...]
In-Reply-To: <1110054526.4902.80.camel@localhost.localdomain>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
	<Pine.LNX.4.61.0503032246580.10083@netcore.fi>
	<20050303210630.GA4513@srv01.cluenet.de>
	<1109884466.12887.11.camel@jkeating2.hq.pogolinux.com>
	<20050305182537.GA31049@srv01.cluenet.de>
	<1110054526.4902.80.camel@localhost.localdomain>
Message-ID: <20050305204747.GA32386@srv01.cluenet.de>

On Sat, Mar 05, 2005 at 12:28:46PM -0800, Jesse Keating wrote:
> 1) we can't announce testing packages to Bugtraq, and I'd rather not do
> it to Fedora Legacy Announce either.  These are reserved for released
> packages.  But we will announce to Fedora Legacy List when we have a new
> package for testing, just as we do now.

I could live with that. Perhaps a fedora-test-announce would make sense.
The annoucement isn't that important, the availability of RPMs is. :-)


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From marcdeslauriers at videotron.ca  Sat Mar  5 23:38:07 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sat, 05 Mar 2005 18:38:07 -0500
Subject: Fedora Legacy Test Update Notification: shadow-utils
In-Reply-To: <4229F66A.8010603@videotron.ca>
References: <4229F66A.8010603@videotron.ca>
Message-ID: <1110065887.25426.2.camel@mdlinux>

On Sat, 2005-03-05 at 13:11 -0500, Marc Deslauriers wrote:
> ---------------------------------------------------------------------
> Fedora Legacy Test Update Notification
> FEDORALEGACY-2005-2253
> Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2253
> 2005-03-05
> ---------------------------------------------------------------------
> 
> Name        : shadow-utils

I have removed these packages from the updates-testing directory.

It turns out the code that had the security issue wasn't even being
shipped in the binary packages by the SPEC file. There is no reason to
issue updates.

There is no harm done is someone installed these testing packages in the
meantime.

Marc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050305/5e8fb7f5/attachment.sig>

From peak at argo.troja.mff.cuni.cz  Sat Mar  5 23:59:43 2005
From: peak at argo.troja.mff.cuni.cz (Pavel Kankovsky)
Date: Sun, 6 Mar 2005 00:59:43 +0100 (CET)
Subject: Fedora Legacy Test Update Notification: dhcp
In-Reply-To: <4229C82F.9010002@videotron.ca>
Message-ID: <20050305235943.12935.qmail@paddy.troja.mff.cuni.cz>

On Sat, 5 Mar 2005, Marc Deslauriers wrote:

> Xpdf is a DHCP (Dynamic Host Configuration Protocol) server and
> relay agent.

No, it is not. Xpdf is a PDF viewer.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."



From jimpop at yahoo.com  Sun Mar  6 00:24:36 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Sat, 05 Mar 2005 19:24:36 -0500
Subject: Fedora Legacy Test Update Notification: dhcp
In-Reply-To: <20050305235943.12935.qmail@paddy.troja.mff.cuni.cz>
References: <20050305235943.12935.qmail@paddy.troja.mff.cuni.cz>
Message-ID: <1110068676.12313.4.camel@blue>

On Sun, 2005-03-06 at 00:59 +0100, Pavel Kankovsky wrote:
> On Sat, 5 Mar 2005, Marc Deslauriers wrote:
> 
> > Xpdf is a DHCP (Dynamic Host Configuration Protocol) server and
> > relay agent.
> 
> No, it is not. Xpdf is a PDF viewer.

Mark must be checking to see if anyone really pays attention to his
detail. ;-)

-Jim P.






From dom at earth.li  Sun Mar  6 01:10:12 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Sun, 6 Mar 2005 01:10:12 +0000
Subject: how to get started with helping the project [...]
In-Reply-To: <1110054526.4902.80.camel@localhost.localdomain>
References: <421E9E0E.1030000@videotron.ca>
	<200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
	<Pine.LNX.4.61.0503032246580.10083@netcore.fi>
	<20050303210630.GA4513@srv01.cluenet.de>
	<1109884466.12887.11.camel@jkeating2.hq.pogolinux.com>
	<20050305182537.GA31049@srv01.cluenet.de>
	<1110054526.4902.80.camel@localhost.localdomain>
Message-ID: <20050306011012.GS987@tirian.magd.ox.ac.uk>

On Sat, Mar 05, 2005 at 12:28:46PM -0800, Jesse Keating wrote:

> 1) we can't announce testing packages to Bugtraq, and I'd rather not do
> it to Fedora Legacy Announce either.  These are reserved for released
> packages.  But we will announce to Fedora Legacy List when we have a new
> package for testing, just as we do now.

Actually, I'm not convinced posting to bugtraq is worthwhile. It's just
increasing the noise levels on that list, and people seem to be posting
directly to it less as far as vendor security updates goes; maybe we
should follow suit.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



From marcdeslauriers at videotron.ca  Sun Mar  6 01:57:57 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sat, 05 Mar 2005 20:57:57 -0500
Subject: Fedora Legacy Test Update Notification: dhcp
In-Reply-To: <20050305235943.12935.qmail@paddy.troja.mff.cuni.cz>
References: <20050305235943.12935.qmail@paddy.troja.mff.cuni.cz>
Message-ID: <1110074278.29773.1.camel@mdlinux>

On Sun, 2005-03-06 at 00:59 +0100, Pavel Kankovsky wrote:
> > Xpdf is a DHCP (Dynamic Host Configuration Protocol) server and
> > relay agent.
> 
> No, it is not. Xpdf is a PDF viewer.

humm...no wonder I could never get it to give out ip addresses. :)

Thanks for catching that, the text will be corrected for the official
advisory.

Marc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050305/067a9ed9/attachment.sig>

From marcdeslauriers at videotron.ca  Sun Mar  6 02:01:42 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sat, 05 Mar 2005 21:01:42 -0500
Subject: Fedora Legacy Test Update Notification: dhcp
In-Reply-To: <1110068676.12313.4.camel@blue>
References: <20050305235943.12935.qmail@paddy.troja.mff.cuni.cz>
	<1110068676.12313.4.camel@blue>
Message-ID: <1110074503.29773.4.camel@mdlinux>

On Sat, 2005-03-05 at 19:24 -0500, Jim Popovitch wrote:
> > No, it is not. Xpdf is a PDF viewer.
> 
> Mark must be checking to see if anyone really pays attention to his
> detail. ;-)

Looks like we'll need to add "Proofreader" to the list of positions we
need filled. :)

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050305/4e1b63f8/attachment.sig>

From dr at cluenet.de  Sun Mar  6 03:22:10 2005
From: dr at cluenet.de (Daniel Roesen)
Date: Sun, 6 Mar 2005 04:22:10 +0100
Subject: how to get started with helping the project [...]
In-Reply-To: <20050306011012.GS987@tirian.magd.ox.ac.uk>
References: <200503031453.05137.guallar@easternrad.com>
	<1109880271.13515.1.camel@blue>
	<200503031518.53988.guallar@easternrad.com>
	<1109882195.13515.21.camel@blue>
	<Pine.LNX.4.61.0503032246580.10083@netcore.fi>
	<20050303210630.GA4513@srv01.cluenet.de>
	<1109884466.12887.11.camel@jkeating2.hq.pogolinux.com>
	<20050305182537.GA31049@srv01.cluenet.de>
	<1110054526.4902.80.camel@localhost.localdomain>
	<20050306011012.GS987@tirian.magd.ox.ac.uk>
Message-ID: <20050306032210.GA2535@srv01.cluenet.de>

On Sun, Mar 06, 2005 at 01:10:12AM +0000, Dominic Hargreaves wrote:
> On Sat, Mar 05, 2005 at 12:28:46PM -0800, Jesse Keating wrote:
> Actually, I'm not convinced posting to bugtraq is worthwhile. It's just
> increasing the noise levels on that list, and people seem to be posting
> directly to it less as far as vendor security updates goes; maybe we
> should follow suit.

Agreed. The vendor announcement flooding of the Linux/BSD distros
are really just noise, as those are normally only a reaction to another
advisory. Users of a distro should subscribe to their specific
announcement list.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0



From bedouglas at earthlink.net  Sun Mar  6 21:37:43 2005
From: bedouglas at earthlink.net (bruce)
Date: Sun, 6 Mar 2005 13:37:43 -0800
Subject: upgrading rh to fc 3
Message-ID: <00fd01c52294$bbc56ff0$0301a8c0@Mesa.com>

hi...

i'm trying to find out if there's a way to put the fc3 iso files on an ftp
server on my network, and then remotely access each machine that i want to
update to fc3, and somehow upgrade the machine to fc3 remotely. is there
some app that i have to load/install/run on the remote machine...???

i've searched google and can't figure out how to do this...

any ideas/pointers/solutions/etc.. will be helpful.

thanks

bruce
bedouglas at earthlink.net



From dsccable at comcast.net  Sun Mar  6 22:12:17 2005
From: dsccable at comcast.net (David Curry)
Date: Sun, 06 Mar 2005 17:12:17 -0500
Subject: upgrading rh to fc 3
In-Reply-To: <00fd01c52294$bbc56ff0$0301a8c0@Mesa.com>
References: <00fd01c52294$bbc56ff0$0301a8c0@Mesa.com>
Message-ID: <422B8041.40009@comcast.net>

bruce wrote:

>hi...
>
>i'm trying to find out if there's a way to put the fc3 iso files on an ftp
>server on my network, and then remotely access each machine that i want to
>update to fc3, and somehow upgrade the machine to fc3 remotely. is there
>some app that i have to load/install/run on the remote machine...???
>
>i've searched google and can't figure out how to do this...
>
>any ideas/pointers/solutions/etc.. will be helpful.
>
>thanks
>
>bruce
>bedouglas at earthlink.net
>
>  
>
You are posting to the wrong list, Bruce.  FC2 is not legacy yet, much 
less FC3.  Try fedora-list.



From dom at earth.li  Sun Mar  6 23:19:47 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Sun, 6 Mar 2005 23:19:47 +0000
Subject: Round-up, 2005-03-06
Message-ID: <20050306231946.GA30563@home.thedom.org>

$Id: issues.txt,v 1.200 2005/03/06 23:14:29 dom Exp $

See bottom for changes

This list is also available at
http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt

Packages that have been verified and should be fully released
-------------------------------------------------------------

subversion - https://bugzilla.fedora.us/show_bug.cgi?id=1748
php - https://bugzilla.fedora.us/show_bug.cgi?id=2344

Packages waiting to be built for updates-testing
------------------------------------------------

openoffice - https://bugzilla.fedora.us/show_bug.cgi?id=2074
kdefax - https://bugzilla.fedora.us/show_bug.cgi?id=2164
imap - https://bugzilla.fedora.us/show_bug.cgi?id=2443
postgresql - https://bugzilla.fedora.us/show_bug.cgi?id=2260
sudo - http://bugzilla.fedora.us/show_bug.cgi?id=2291
less - https://bugzilla.fedora.us/show_bug.cgi?id=2404
krb5 - https://bugzilla.fedora.us/show_bug.cgi?id=2040

Packages in state RESOLVED (ie exist in updates-testing) that need
active work.
------------------------------------------------------------------

redhat-config-nfs - https://bugzilla.fedora.us/show_bug.cgi?id=2086
Needs VERIFY [rh9,fc1]

rp-pppoe - https://bugzilla.fedora.us/show_bug.cgi?id=2116
Needs VERIFY [rh73,rh9,fc1]

lesstiff - https://bugzilla.fedora.us/show_bug.cgi?id=2142
Needs VERIFY [rh73,rh9,fc1]

openmotif - https://bugzilla.fedora.us/show_bug.cgi?id=2143
Needs VERIFY [fc1]

sharutils - https://bugzilla.fedora.us/show_bug.cgi?id=2155
Needs VERIFY [fc1]

nfs-utils - https://bugzilla.fedora.us/show_bug.cgi?id=2339
Needs VERIFY [rh73,fc1]

mailman - https://bugzilla.fedora.us/show_bug.cgi?id=2419
Needs VERIFY [rh73]

samba - https://bugzilla.fedora.us/show_bug.cgi?id=2349
Needs VERIFY [rh9,fc1]

ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007
Needs VERIFY [fc1]

qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002
Needs VERIFY [rh73]

squid - https://bugzilla.fedora.us/show_bug.cgi?id=2150
Needs VERIFY [rh73,rh9,fc1]

mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2129
Needs VERIFY [fc1]

ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=2407
Needs VERIFY [fc1]

squirrelmail - https://bugzilla.fedora.us/show_bug.cgi?id=2424
Needs VERIFY [rh9,fc1]

gtk2 - https://bugzilla.fedora.us/show_bug.cgi?id=2073
Needs VERIFY [rh73,rh9]

kdelibs - https://bugzilla.fedora.us/show_bug.cgi?id=2008
Needs VERIFY [rh73,rh9,fc1]

libtiff - https://bugzilla.fedora.us/show_bug.cgi?id=2163
Needs VERIFY [rh73,rh9,fc1]

libgd - https://bugzilla.fedora.us/show_bug.cgi?id=2254
Needs VERIFY [rh73,rh9,fc1]

spamassassin - https://bugzilla.fedora.us/show_bug.cgi?id=2268
Needs VERIFY [rh9]

dhcp - https://bugzilla.fedora.us/show_bug.cgi?id=2251
Needs VERIFY [rh73]

pam_wheel - https://bugzilla.fedora.us/show_bug.cgi?id=2010
Needs VERIFY [rh73,rh9]

Packages in state UNCONFIRMED, NEW, ASSIGNED or REOPENED:
--------------------------------------------------------

readline - https://bugzilla.fedora.us/show_bug.cgi?id=2017
decision on whether to release [rh9]

imlib - https://bugzilla.fedora.us/show_bug.cgi?id=2051
Needs PUBLISH [rh9] and package for fc1

security.conf - https://bugzilla.fedora.us/show_bug.cgi?id=2146
Needs QA [fc1,rh9], packages [rh9], discussion of updated extras

libxml2 - https://bugzilla.fedora.us/show_bug.cgi?id=2207
Needs PUBLISH [rh73,rh9,fc1], more work?

links - https://bugzilla.fedora.us/show_bug.cgi?id=2213
Needs packages/investigation

lynx - https://bugzilla.fedora.us/show_bug.cgi?id=2215
Needs investigation/packages

w3m - https://bugzilla.fedora.us/show_bug.cgi?id=2216
Needs investigation/packages

openssl - https://bugzilla.fedora.us/show_bug.cgi?id=2257
Needs investigation/packages

lvm - https://bugzilla.fedora.us/show_bug.cgi?id=2258
Needs PUBLISH [rh73,rh9,fc1]

netatalk - https://bugzilla.fedora.us/show_bug.cgi?id=2259
Needs PUBLICH [rh73,rh9,fc1]

perl - https://bugzilla.fedora.us/show_bug.cgi?id=2261
Needs investigation/packages

glibc - https://bugzilla.fedora.us/show_bug.cgi?id=2265
Needs investigation/packages

ghostscript - https://bugzilla.fedora.us/show_bug.cgi?id=2266
Needs investigation/packages

file - https://bugzilla.fedora.us/show_bug.cgi?id=2331
Needs investigation/packages

rpm - https://bugzilla.fedora.us/show_bug.cgi?id=2333
Haven't we seen this in some other bug?

pdflatex - https://bugzilla.fedora.us/show_bug.cgi?id=2334
Needs PUBLISH [rh9], packages [rh73,fc1]

a2ps - https://bugzilla.fedora.us/show_bug.cgi?id=2338
Needs PUBLISH [rh73,rh9,fc1]

wget - https://bugzilla.fedora.us/show_bug.cgi?id=2340
Needs investigation/packages

namazu - https://bugzilla.fedora.us/show_bug.cgi?id=2342
Needs investigation/packages

xine - https://bugzilla.fedora.us/show_bug.cgi?id=2348
Needs PUBLISH [rh73]

glibc - https://bugzilla.fedora.us/show_bug.cgi?id=2354
Minor but could be included if another glibc is needed

mozilla - https://bugzilla.fedora.us/show_bug.cgi?id=2380
Needs work

cpio - https://bugzilla.fedora.us/show_bug.cgi?id=2408
Needs PUBLISH [rh9,fc1]

enscript - https://bugzilla.fedora.us/show_bug.cgi?id=2409
PUBLISH [rh73,rh9,fc1]

mod_python - https://bugzilla.fedora.us/show_bug.cgi?id=2420
Needs work

python - https://bugzilla.fedora.us/show_bug.cgi?id=2421
Needs work

movemail - https://bugzilla.fedora.us/show_bug.cgi?id=2422
Needs work

xemacs - https://bugzilla.fedora.us/show_bug.cgi?id=2423
Needs work

evolution - https://bugzilla.fedora.us/show_bug.cgi?id=2427
Needs work

ncpfs - https://bugzilla.fedora.us/show_bug.cgi?id=2428
Needs work

nasm - https://bugzilla.fedora.us/show_bug.cgi?id=2429
Needs work

htdig - https://bugzilla.fedora.us/show_bug.cgi?id=2431
Needs work

mc - https://bugzilla.fedora.us/show_bug.cgi?id=2405
Needs work

gftp - https://bugzilla.fedora.us/show_bug.cgi?id=2440
Needs work

digestmd5 - https://bugzilla.fedora.us/show_bug.cgi?id=2441
Double check non-vuln

emacs - https://bugzilla.fedora.us/show_bug.cgi?id=2422
Needs work

ImageMagick - https://bugzilla.fedora.us/show_bug.cgi?id=2052
Needs PUBLISH [rh73,rh9,fc1] (more work)

General (non-package bugs)
--------------------------

sample yum.conf - https://bugzilla.fedora.us/show_bug.cgi?id=2140
up2date - https://bugzilla.fedora.us/show_bug.cgi?id=2193
up2date - https://bugzilla.fedora.us/show_bug.cgi?id=2194
updates - http://bugzilla.fedora.us/show_bug.cgi?id=2281
up2date - http://bugzilla.fedora.us/show_bug.cgi?id=2306
yum - https://bugzilla.fedora.us/show_bug.cgi?id=2330

Notes
-----

Needs PUBLISH means that there are packages available for QA that need
to be QAd at the source level.

Needs VERIFY means that there are updates-testing packages that need
testing. This is the easy bit, let's get this old ones out of the way
ASAP.

* means that there is a judgement call that can be made on the bug
system immediately. Please follow up onlist with opinions.

Changes
-------

I've removed the changelog as it contains little of interest.
The full history of this file is available as an RCS file at:
http://www-astro.physics.ox.ac.uk/~dom/legacy/issues.txt,v
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050306/52d3126b/attachment.sig>

From dom at earth.li  Sun Mar  6 23:21:13 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Sun, 6 Mar 2005 23:21:13 +0000
Subject: Speaking of contributions...
In-Reply-To: <Pine.LNX.4.61.0503042041020.14497@risby.gatekeeper.ltd.uk>
References: <Pine.LNX.4.61.0503042214430.11031@netcore.fi>
	<Pine.LNX.4.61.0503042041020.14497@risby.gatekeeper.ltd.uk>
Message-ID: <20050306232113.GV987@tirian.magd.ox.ac.uk>

On Fri, Mar 04, 2005 at 08:47:07PM +0000, Tom Yates wrote:
> personally, i miss dom's periodic round-up mails.  yes, i know i can get 
> exactly the same thing on the web, but whenever it came around i made a 
> point of seeing if there was anything i could work on, and when i yum'ed a 
> -testing package onto my server, i went straight to the roundup to find 
> the bugzilla page to log my +VERIFY.
> 
> dom, is there any chance you'd consider posting these regularly?

They're still being posted, when I get a chance. I very much hope that
we will be able to get bugzilla set up such that my list will become
unnecessary, once it's moved to redhat.

Cheers,

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



From marcdeslauriers at videotron.ca  Mon Mar  7 00:26:49 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sun, 06 Mar 2005 19:26:49 -0500
Subject: Fedora Legacy Test Update Notification: spamassassin
Message-ID: <422B9FC9.5070301@videotron.ca>

This version adds a better patch.

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2268
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2268
2005-03-06
---------------------------------------------------------------------

Name        : spamassassin
Versions    : fc1: spamassassin-2.63-0.2.2.legacy
Summary     : Spam filter for email which can be invoked from mail
               delivery agents.
Description :
SpamAssassin provides you with a way to reduce if not completely
eliminate Unsolicited Commercial Email (SPAM) from your incoming email.
It can be invoked by a MDA such as sendmail or postfix, or can be called
from a procmail script, .forward file, etc.  It uses a genetic-algorithm
evolved scoring system to identify messages which look spammy, then
adds headers to the message so they can be filtered by the user's mail
reading software.  This distribution includes the spamd/spamc components
which create a server that considerably speeds processing of mail.

---------------------------------------------------------------------
Update Information:

An updated spamassassin package that fixes a denial of service bug when
parsing malformed messages is now available.

SpamAssassin provides a way to reduce unsolicited commercial email
(SPAM) from incoming email.

A denial of service bug has been found in SpamAssassin versions below
2.64. A malicious attacker could construct a message in such a way that
would cause spamassassin to stop responding, potentially preventing the
delivery or filtering of email. The Common Vulnerabilities and Exposures
project (cve.mitre.org) has assigned the name CAN-2004-0796 to this
issue.

Users of SpamAssassin should update to these updated packages which
contain a backported patch and is not vulnerable to this issue.

---------------------------------------------------------------------
Changelogs

fc1:
* Sun Dec 19 2004 Pekka Savola <pekkas at netcore.fi> 2.63-0.2.2.legacy
- more extensive patch for CAN-2004-0796 (from 2.64)

* Tue Nov 16 2004 Rob Myers <rob.myers at gtri.gatech.edu> 2.63-0.2.1.legacy
- patch for CAN-2004-0796 (FL #2268)

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

fc1:
e76200ac598d6cb56ec18b92cfe6ce6af0181683 
fedora/1/updates-testing/i386/spamassassin-2.63-0.2.2.legacy.i386.rpm
21e17d5e33e8ba6bf76c288544719169982bb415 
fedora/1/updates-testing/SRPMS/spamassassin-2.63-0.2.2.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050306/d1cfe14d/attachment.sig>

From marcdeslauriers at videotron.ca  Mon Mar  7 00:27:20 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sun, 06 Mar 2005 19:27:20 -0500
Subject: Fedora Legacy Test Update Notification: krb5
Message-ID: <422B9FE8.9080402@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2040
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2040
2005-03-06
---------------------------------------------------------------------

Name        : krb5
Versions    : rh7.3: krb5-1.2.4-16.legacy
Versions    : rh9: krb5-1.2.7-38.2.legacy
Versions    : fc1: krb5-1.3.4-5.2.legacy
Summary     : Kerberos 5 programs for use on workstations.
Description :
Kerberos is a network authentication system. The krb5-workstation
package contains the basic Kerberos programs (kinit, klist, kdestroy,
kpasswd) as well as kerberized versions of Telnet and FTP. If your
network uses Kerberos, this package should be installed on every
workstation.

---------------------------------------------------------------------
Update Information:

Updated Kerberos (krb5) packages that correct multiple security issues
are now available.

Kerberos is a networked authentication system that uses a trusted third
party (a KDC) to authenticate clients and servers to each other.

Note that some of these issues have already been fixed in Fedora Core 1.
Please refer to previous advisories for details.

Several buffer overflows were possible for all Kerberos versions up to
and including 1.3.3 in the krb5_aname_to_localname library function. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0523 to this issue.

Several double-free bugs were found in the Kerberos 5 KDC and libraries.
A remote attacker could potentially exploit these flaws to execuate
arbitrary code. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the names CAN-2004-0642 and CAN-2004-0643
to these issues.

A double-free bug was also found in the krb524 server. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-0772 to this issue.

An infinite loop bug was found in the Kerberos 5 ASN.1 decoder library.
A remote attacker may be able to trigger this flaw and cause a denial of
service. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2004-0644 to this issue.

A heap based buffer overflow bug was found in the administration library
of Kerberos 1.3.5 and earlier. This bug could allow an authenticated
remote attacker to execute arbitrary commands on a realm's master
Kerberos KDC. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2004-1189 to this issue.

Additionally a temporary file bug was found in the Kerberos krb5-send-pr
program. It is possible that an attacker could create a temporary file
that would allow an arbitrary file to be overwritten which the victim
has write access to. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2004-0971 to this issue.

All users of krb5 should upgrade to these updated packages, which
contain backported security patches to resolve these issues.

---------------------------------------------------------------------
Changelogs

rh73:
* Sun Mar 06 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
1.2.4-16.legacy
- Added missing libtool BuildPrereq

* Sat Feb 26 2005 Pekka Savola <pekkas at netcore.fi> 1.2.4-15.legacy
- apply ~all patches from RHEL21 between 1.2.2-24 to -32 (#2040)
- don't apply DNS usage patch, as it would be a new feature

rh9:
* Sun Mar 06 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
1.2.7-38.2.legacy
- Added missing libtool and autoconf213 to BuildPrereq

* Sat Feb 26 2005 Pekka Savola <pekkas at netcore.fi> 1.2.7-38.1.legacy
- Rebuild for Fedora Legacy, to fix a number of bugs (#2040)

* Wed Dec 22 2004 Nalin Dahyabhai <nalin at redhat.com> 1.2.7-38
- add additional hunk to fix for #123031 for xdr encoding/decoding of gssapi
   buffers (part of #143127)

fc1:
* Sun Mar 06 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
1.3.4-5.2.legacy
- Added missing autoconf BuildPrereq

* Wed Mar 02 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
1.3.4-5.1.legacy
- Added security patches for CAN-2004-0971 and CAN-2004-1189

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
50bbcee234a516ecdb33ddcc7fc5c8b1a5f3b5cd 
redhat/7.3/updates-testing/i386/krb5-devel-1.2.4-16.legacy.i386.rpm
5b8e4296a97f8ac0b5fb38fb634226216fc7a7bc 
redhat/7.3/updates-testing/i386/krb5-libs-1.2.4-16.legacy.i386.rpm
ea278b24980c972694b0f2f6715656eacad4165f 
redhat/7.3/updates-testing/i386/krb5-server-1.2.4-16.legacy.i386.rpm
fa8d49d3d9a3827b2862585a028ffdd42334e9d4 
redhat/7.3/updates-testing/i386/krb5-workstation-1.2.4-16.legacy.i386.rpm
160e8be6a52f236e9a15ac7e5f6bbcdbd34201f8 
redhat/7.3/updates-testing/SRPMS/krb5-1.2.4-16.legacy.src.rpm

rh9:
9bbac59bcc35c8a4cf2a3f201c42b66b9a1ac71d 
redhat/9/updates-testing/i386/krb5-devel-1.2.7-38.2.legacy.i386.rpm
126972c72a03391b34af7f20fafc282859d4c11a 
redhat/9/updates-testing/i386/krb5-libs-1.2.7-38.2.legacy.i386.rpm
89829ef757ddd4fe0605d607c662e85ee7297012 
redhat/9/updates-testing/i386/krb5-server-1.2.7-38.2.legacy.i386.rpm
ce1aaade9eefba47ff00f9832866ac14d44d4f46 
redhat/9/updates-testing/i386/krb5-workstation-1.2.7-38.2.legacy.i386.rpm
32033e8aa82973774b2e5e77a3d34b6b40fbf56c 
redhat/9/updates-testing/SRPMS/krb5-1.2.7-38.2.legacy.src.rpm

fc1:
0a9368bd99b7256632708849eaeb9fdc3e7bdd17 
fedora/1/updates-testing/i386/krb5-devel-1.3.4-5.2.legacy.i386.rpm
08c1b15601aa138b7fb3652cd5a20bb2325d27bc 
fedora/1/updates-testing/i386/krb5-libs-1.3.4-5.2.legacy.i386.rpm
d90437351de986298fd619325a5794626905959e 
fedora/1/updates-testing/i386/krb5-server-1.3.4-5.2.legacy.i386.rpm
f654069f92aabd66bb836210d4918039b7a161ac 
fedora/1/updates-testing/i386/krb5-workstation-1.3.4-5.2.legacy.i386.rpm
ecfd7f697814343945becd0fdd717b11c239152e 
fedora/1/updates-testing/SRPMS/krb5-1.3.4-5.2.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050306/7907cbae/attachment.sig>

From michal at harddata.com  Mon Mar  7 01:58:59 2005
From: michal at harddata.com (Michal Jaegermann)
Date: Sun, 6 Mar 2005 18:58:59 -0700
Subject: Fedora Legacy Test Update Notification: spamassassin
In-Reply-To: <422B9FC9.5070301@videotron.ca>;
	from marcdeslauriers@videotron.ca on Sun, Mar 06, 2005 at
	07:26:49PM -0500
References: <422B9FC9.5070301@videotron.ca>
Message-ID: <20050306185859.A19246@mail.harddata.com>

On Sun, Mar 06, 2005 at 07:26:49PM -0500, Marc Deslauriers wrote:
....
> 
> Name        : spamassassin
> Versions    : fc1: spamassassin-2.63-0.2.2.legacy

It seems to me that this is one of these infrequent examples where
running anything but the current released version, and as a
corollary maintaining something older, is just a waste of time.
Spammers do adjust to a way old versions were testings and I know
from the real world experience that updating makes a real
difference.  Last week spamassassin stopped over ten thousands
emails addressed directly to me.  Without filtering my email would
be useless.

   Michal



From marcdeslauriers at videotron.ca  Mon Mar  7 03:42:34 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sun, 06 Mar 2005 22:42:34 -0500
Subject: Fedora Legacy Test Update Notification: spamassassin
In-Reply-To: <20050306185859.A19246@mail.harddata.com>
References: <422B9FC9.5070301@videotron.ca>
	<20050306185859.A19246@mail.harddata.com>
Message-ID: <1110166955.31809.16.camel@mdlinux>

On Sun, 2005-03-06 at 18:58 -0700, Michal Jaegermann wrote:
> On Sun, Mar 06, 2005 at 07:26:49PM -0500, Marc Deslauriers wrote:
> ....
> > 
> > Name        : spamassassin
> > Versions    : fc1: spamassassin-2.63-0.2.2.legacy
> 
> It seems to me that this is one of these infrequent examples where
> running anything but the current released version, and as a
> corollary maintaining something older, is just a waste of time.
> Spammers do adjust to a way old versions were testings and I know
> from the real world experience that updating makes a real
> difference.  Last week spamassassin stopped over ten thousands
> emails addressed directly to me.  Without filtering my email would
> be useless.

I agree that the latest spamassassin is required in order to maintain an
up-to-date antispam setup. But for security's sake, there are three
options that FL can take here:

1- Update to the latest spamassassin version (3.0.2)

This option is a major upgrade and may very well break some people's
setups. I know of a bunch of people who have spamassassin installed with
MailScanner or some other software and who never upgraded it as it's
"good enough" or they don't have the required know-how to do so. Should
FL update spamassassin and simply say in the release notes "This may
break your setup and/or require updates of other installed software"? I
think it's important for people to be able to depend on the fact that
they can do a "yum update" and keep up with security patches without
breaking their servers every time. I think this option is unacceptable.

2- Don't issue a security update at all

Because the 2.x version of spamassassin is relatively useless in keeping
up with antispam techniques, FL could just assume people have already
upgraded to 3.x and not release an update. What about mail servers that
have 2.x installed and the amount of spam that is getting through is
acceptable? Does FL let them be affected by a potential DoS because we
think they should upgrade to 3.x? What about if the security issue was
more serious, like a remote root compromise? Where do we draw the line?

3- Issue a patch for the current, obsolete, version

Even though we know spamassassin 2.x is obsolete, at least we fix the
security issues present in production servers. If people have already
upgraded to 3.x, then this update will not affect them. If they are
using 2.x, then FL provides the security update that will keep their
server running smoothly. Is this option a waste of time? Maybe, but I
can see no other reasonable option. This is the option Red Hat usually
takes.

Is there any way we could be doing this any better?

Marc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050306/ca840ccd/attachment.sig>

From michal at harddata.com  Mon Mar  7 05:14:10 2005
From: michal at harddata.com (Michal Jaegermann)
Date: Sun, 6 Mar 2005 22:14:10 -0700
Subject: Fedora Legacy Test Update Notification: spamassassin
In-Reply-To: <1110166955.31809.16.camel@mdlinux>;
	from marcdeslauriers@videotron.ca on Sun, Mar 06, 2005 at
	10:42:34PM -0500
References: <422B9FC9.5070301@videotron.ca>
	<20050306185859.A19246@mail.harddata.com>
	<1110166955.31809.16.camel@mdlinux>
Message-ID: <20050306221410.A22059@mail.harddata.com>

On Sun, Mar 06, 2005 at 10:42:34PM -0500, Marc Deslauriers wrote:
....
> 
> 2- Don't issue a security update at all
.....
> 
> 3- Issue a patch for the current, obsolete, version
....
> 
> Is there any way we could be doing this any better?

Well, the original mozilla which came with RH7.3 was mozilla-0.9.9.
It got bumped up in Red Hat updates to version 1.2, I think.  The
current one from legacy updates is mozilla-1.4.3.  As a matter of
fact this was the only reasonable decision AFAICT (and RHEL got some
updates to that in the meantime).  I did actually looked once at a
possibility of doing backport fixes here and quickly decided that
there is no way I can do such thing with any amount of confidence
that results will be even remotely correct not even mentioning time
which would be required for such operation.

I understand very well reasons for "only fixes" policy but there are
situations where this becomes too rigid or unsustainable.  OTOH
"holding a dam" has clear merits but it also may cause a waste of
scarce resources.  No, I do not have clearcut answers which would
be applicable on every occasion.

  Michal



From pxs00354 at nifty.ne.jp  Mon Mar  7 09:43:23 2005
From: pxs00354 at nifty.ne.jp (Methodology at Nifty)
Date: Mon, 07 Mar 2005 18:43:23 +0900
Subject: Demand: porting of iptables-1.2.8-12.3 to fedora legacy systems
Message-ID: <1110188603.5507.39.camel@papa01.tomitas.net>

Hi,

I eventually found out a bug-fixed version of iptables for RHEL3. 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111999

However, the latest version of iptables for the legacy RH9 is still
1.2.8-8.90.1. I am running my own rc script on the RH9 firewall as a
workaround, the bug-fix to RH9 is still in the state of demand.

Any idea ?

Methodology at Nifty 



From pekkas at netcore.fi  Mon Mar  7 12:24:21 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Mon, 7 Mar 2005 14:24:21 +0200 (EET)
Subject: Fedora Legacy Test Update Notification: spamassassin
In-Reply-To: <20050306221410.A22059@mail.harddata.com>
References: <422B9FC9.5070301@videotron.ca>
	<20050306185859.A19246@mail.harddata.com>
	<1110166955.31809.16.camel@mdlinux>
	<20050306221410.A22059@mail.harddata.com>
Message-ID: <Pine.LNX.4.61.0503071422351.561@netcore.fi>

On Sun, 6 Mar 2005, Michal Jaegermann wrote:
> I understand very well reasons for "only fixes" policy but there are
> situations where this becomes too rigid or unsustainable.  OTOH
> "holding a dam" has clear merits but it also may cause a waste of
> scarce resources.  No, I do not have clearcut answers which would
> be applicable on every occasion.

spamassassin 2.64 is better than no spamassassin.

update from 2.64 to 3.02 is non-trivial (requires user 
reconfiguration, depending on the settings used) and we shouldn't do 
that, IMHO.

(FWIW, I have no problem in general with bumping up the versions, but 
I don't think we can do that when we know it's going to break the 
configs of our users..)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From marcdeslauriers at videotron.ca  Mon Mar  7 13:00:27 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Mon, 07 Mar 2005 08:00:27 -0500
Subject: Fedora Legacy Test Update Notification: less
Message-ID: <422C506B.1080703@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2404
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2404
2005-03-07
---------------------------------------------------------------------

Name        : less
Versions    : rh9: less-378-7.2.legacy
Summary     : A text file browser similar to more, but with additional
               capabilities.
Description :
The less utility is a text file browser that resembles more, but has
more capabilities. Less allows you to move backwards in the file as
well as forwards. Since less does not have to read the entire input
file before it starts, less starts up more quickly than text editors.

---------------------------------------------------------------------
Update Information:

An updated less package that fixes segmentation fault when viewing
binary files is now available.

The less utility is a text file browser that resembles more, but has
extended capabilities.

Victor Ashik discovered a heap based buffer overflow in less, caused by
a patch added to the less package in Red Hat Linux 9. An attacker could
construct a carefully crafted file that could cause less to crash or
possibly execute arbitrary code when opened. The Common Vulnerabilities
and Exposures project (cve.mitre.org) has assigned the name
CAN-2005-0086 to this issue.

All users of the less package should upgrade to this updated package,
which resolves this issue.

---------------------------------------------------------------------
Changelogs

rh9:
* Sun Mar 06 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
378-7.2.legacy
- Added missing autoconf to BuildRequires

* Tue Feb 15 2005 Pekka Savola <pekkas at netcore.fi> 378-7.1.legacy
- Fix CAN-2005-0086 (#2404) from RHEL3.

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh9:
08f54de18179fdaf849cd26d0497531426fd9cc6 
redhat/9/updates-testing/i386/less-378-7.2.legacy.i386.rpm
58ccb5a8cdb72c2a64cd8b41ba8984f2df906a18 
redhat/9/updates-testing/SRPMS/less-378-7.2.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050307/e46ccba3/attachment.sig>

From marcdeslauriers at videotron.ca  Mon Mar  7 13:00:59 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Mon, 07 Mar 2005 08:00:59 -0500
Subject: Fedora Legacy Test Update Notification: sudo
Message-ID: <422C508B.1060204@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2291
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2291
2005-03-07
---------------------------------------------------------------------

Name        : sudo
Versions    : rh7.3: sudo-1.6.5p2-2.2.legacy
Versions    : rh9: sudo-1.6.6-3.2.legacy
Versions    : fc1: sudo-1.6.7p5-2.2.legacy
Summary     : Allows restricted root access for specified users.
Description :
Sudo (superuser do) allows a system administrator to give certain
users (or groups of users) the ability to run some (or all) commands
as root while logging all commands and arguments. Sudo operates on a
per-command basis. It is not a replacement for the shell. Features
include: the ability to restrict what commands a user may run on a
per-host basis, copious logging of each command (providing a clear
audit trail of who did what), a configurable timeout of the sudo
command, and the ability to use the same configuration file (sudoers)
on many different machines.

---------------------------------------------------------------------
Update Information:

Updated sudo packages that fix a security issue are now available.

Sudo (superuser do) allows a system administrator to give certain
users (or groups of users) the ability to run some (or all) commands
as root while logging all commands and arguments.

A flaw in exists in sudo's environment sanitizing prior to sudo version
1.6.8p2 that could allow a malicious user with permission to run a shell
script that utilized the bash shell to run arbitrary commands. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-1051 to this issue.

Users of sudo are advised to upgrade to these errata packages, which
contain a patch correcting this issue.

---------------------------------------------------------------------
Changelogs

rh73:
* Sun Mar 06 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
1.6.5p2-2.2.legacy
- Added missing groff to BuildRequires

* Tue Dec 21 2004 Pekka Savola <pekkas at netcore.fi> 1.6.5p2-2.1.legacy
- Fix CAN-2004-1051 (#2291) with patch from Debian.

rh9:
* Sun Mar 06 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
1.6.6-3.2.legacy
- Added missing groff to BuildRequires

* Tue Dec 21 2004 Pekka Savola <pekkas at netcore.fi> 1.6.6-3.1.legacy
- Fix CAN-2004-1051 (#2291) with patch from Debian.

fc1:
* Sun Mar 06 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
1.6.7p5-2.2.legacy
- Added missing groff to BuildRequires

* Tue Dec 21 2004 Pekka Savola <pekkas at netcore.fi> 1.6.7p5-2.1.legacy
- Fix CAN-2004-1051 (#2291) with patch from Debian.

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
19c703b635c9e4299d39b60d9cd16d750a4f6d89 
redhat/7.3/updates-testing/i386/sudo-1.6.5p2-2.2.legacy.i386.rpm
9225335d8ca64ca7e1cb1fd98a09a9821ab9b0d8 
redhat/7.3/updates-testing/SRPMS/sudo-1.6.5p2-2.2.legacy.src.rpm

rh9:
73e1ce58ba8f6c211da4271d8f7a792aa01acba2 
redhat/9/updates-testing/i386/sudo-1.6.6-3.2.legacy.i386.rpm
4a9c1de46d43694ec94688cfc021ade0dc0b1678 
redhat/9/updates-testing/SRPMS/sudo-1.6.6-3.2.legacy.src.rpm

fc1:
a990c5c070acd9ae8c50181487f2f9cdacb38378 
fedora/1/updates-testing/i386/sudo-1.6.7p5-2.2.legacy.i386.rpm
fe6b14daf1f5190e7d39625d6048bb415ba8851c 
fedora/1/updates-testing/SRPMS/sudo-1.6.7p5-2.2.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050307/88d98df1/attachment.sig>

From beartooth at adelphia.net  Fri Mar  4 21:08:49 2005
From: beartooth at adelphia.net (beartooth)
Date: Fri, 04 Mar 2005 16:08:49 -0500
Subject: Error: ... correct GPG keys installed?
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109873341.9846.447.camel@serendipity.dogma.lan>
	<pan.2005.03.03.19.43.46.910288@adelphia.net>
	<1109880833.9846.457.camel@serendipity.dogma.lan>
	<pan.2005.03.04.16.56.35.789396@adelphia.net>
	<1109967662.9846.511.camel@serendipity.dogma.lan>
Message-ID: <pan.2005.03.04.21.08.46.390955@adelphia.net>

On Fri, 04 Mar 2005 21:21:02 +0100, Alexander Dalloz wrote:

> Am Fr, den 04.03.2005 schrieb beartooth um 17:56:
> 
>> Is this ok [y/N]: y
>> warning: rpmts_HdrFromFdno: V3 DSA signature: NOKEY, key ID 8df56d05
>> Error: Could not find the GPG Key necessary to validate pkg
>> /var/cache/yum/fedora-stable/packages/perl-DateManip-5.42-0.fdr.2.a.1.noarch.rpm
>> Error: You may want to run yum clean or remove the file:
>>  /var/cache/yum/fedora-stable/packages/perl-DateManip-5.42-0.fdr.2.a.1.noarch.rpm
>> Error: You may also check that you have the correct GPG keys installed
>> [root at localhost root]#
>>                          =====
> 
> This is
> 
> http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/perl-DateManip-5.42-0.fdr.2.a.1.noarch.rpm
> 
> from fedora.us. Which is a very different repository and uses its own
> GPG key.
> 
> rpm --import http://www.fedora.us/FEDORA-GPG-KEY
> 
THAT worked the blue wonder -- literally : I do things as root only on
terminal tabs with a blue background. Anyway, it was the magic command
that hit the spot. Yum update installed 88 new things, successfully. Many,
many thanks!

-- 
Beartooth Implacable, Linux Evangelist & Gadfly
neo-redneck, curmudgeonly codger with FC1 & YDL 4.0
Pine 4.61, Pan 0.14.2; Privoxy 3.0.1; Opera 7.54, Firefox 1.0
Bear in mind that I have little idea what I am talking about.




From beartooth at adelphia.net  Fri Mar  4 16:48:37 2005
From: beartooth at adelphia.net (beartooth)
Date: Fri, 04 Mar 2005 11:48:37 -0500
Subject: Error: ... correct GPG keys installed?
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109874371.11173.68.camel@blue>
	<1109880636.9846.455.camel@serendipity.dogma.lan>
	<1109880733.13515.4.camel@blue>
	<1109883563.9846.469.camel@serendipity.dogma.lan>
Message-ID: <pan.2005.03.04.16.48.36.260548@adelphia.net>

On Thu, 03 Mar 2005 21:59:23 +0100, Alexander Dalloz wrote:

> But if you look at "Beartooth's" signature you see that he is running
> Fedora Core 1. And I remember him from the Fedora User list as being and
> not very experienced user. So if you confuse him directing into the gpg
> binary usage, that does not help him. He simply does not know anything
> about the GPG signing, I fear (reading his initial posting and reply).

You got me. I did run into GPG problems when I first started using
Clint Harshaw's yum.conf, as I think I said; asked about it; got told what
to do to get the various keys; did it; and happily ran yum for some time.

> I think he is a Fedora Core 1 user and found out lately that security
> updates are coming from the Fedora Legacy Project for his release. And
> as these packages have a different GPG sign than those from Red Hat, he
> now does not know how to install the update packages from FLP. He may
> correct me if I am wrong. If he did read
> 
> http://www.fedoralegacy.org/about/security.php
> 
> at least he didn't understand it.

Right, alas! -- nor did I understand it on reading it again ten minutes
ago. 

When it tells me to do (for Red Hat 8.0 and later) "rpm --import
<keyfile>", does it mean to substitute "FEDORA-LEGACY-GPG-KEY" or all
of "http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY" -- or some third
thing -- for <keyfile>?

I see a note on that site about a bug involving multiple keys, but the
error message it uses as an example does not match what I'm getting. I
don't know what to make of that.

-- 
Beartooth Implacable, Linux Evangelist & Gadfly
neo-redneck, curmudgeonly codger with FC1 & YDL 4.0
Pine 4.61, Pan 0.14.2; Privoxy 3.0.1; Opera 7.54, Firefox 1.0
Bear in mind that I have little idea what I am talking about.




From beartooth at adelphia.net  Fri Mar  4 17:46:11 2005
From: beartooth at adelphia.net (beartooth)
Date: Fri, 04 Mar 2005 12:46:11 -0500
Subject: Error: ... correct GPG keys installed?
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109873341.9846.447.camel@serendipity.dogma.lan>
	<pan.2005.03.03.19.43.46.910288@adelphia.net>
	<1109880833.9846.457.camel@serendipity.dogma.lan>
	<pan.2005.03.04.16.56.35.789396@adelphia.net>
	<1109956705.12887.50.camel@jkeating2.hq.pogolinux.com>
Message-ID: <pan.2005.03.04.17.46.08.30199@adelphia.net>

On Fri, 04 Mar 2005 09:18:24 -0800, Jesse Keating wrote:

>> Perhaps I should mention, or remind people, that the yum.conf file I
>> have
>> goes to several repos. Dunno if that's relevant or not. Will it help,
>> for
>> instance, if I post all the URLs it contains?
> 
> Yes.

Well, I hope I'm not abusing grep; I'll go through by hand if need be.

Also, note that most of them are commented out; if the formatting doesn't
make the rest easy to spot, I'll go back through either all of
/etc/yum.conf, or this output, on a tiny-font terminal tab. I leave them
in on this first pass in case they tell anyone anything.

Here's what I did and got :
                              =====
[root at localhost root]# cat /etc/yum.conf | grep http
# http://www.fedoralegacy.org/download/fedoralegacy-mirrors.php
#    rpm --import http://www.fedoralegacy.org/FEDORA-LEGACY-GPG-KEY
baseurl=http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/fedora/$releasever/os/$basearch
  http://download.fedoralegacy.org/fedora/$releasever/os/$basearch
#  http://mirror.datapipe.net/fedoralegacy/fedora/$releasever/os/$basearch
#  http://mirror3.cs.wisc.edu/pub/mirrors/linux/download.fedoralegacy.org/fedora/$releasever/os/$basearch
baseurl=http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/fedora/$releasever/updates/$basearch
  http://download.fedoralegacy.org/fedora/$releasever/updates/$basearch
#  http://mirror.datapipe.net/fedoralegacy/fedora/$releasever/updates/$basearch
#  http://mirror3.cs.wisc.edu/pub/mirrors/linux/download.fedoralegacy.org/fedora/$releasever/updates/$basearch
baseurl=http://www.gtlib.cc.gatech.edu/pub/fedoralegacy/fedora/$releasever/legacy-utils/$basearch
  http://download.fedoralegacy.org/fedora/$releasever/legacy-utils/$basearch
#  http://mirror.datapipe.net/fedoralegacy/fedora/$releasever/legacy-utils/$basearch
#  http://mirror3.cs.wisc.edu/pub/mirrors/linux/download.fedoralegacy.org/fedora/$releasever/legacy-utils/$basearch
baseurl=http://mirrors.kernel.org/fedora.us/fedora/fedora/$releasever/$basearch/yum/stable
  http://fedora.quicknet.nl/fedora/fedora/$releasever/$basearch/yum/stable
  http://mirrors.usc.edu/pub/linux/fedora/fedora/fedora/$releasever/$basearch/yum/stable
  http://fedora.mirror.sdv.fr/fedora/fedora/$releasever/$basearch/yum/stable
  http://download.fedora.us/fedora/fedora/$releasever/$basearch/yum/stable
#baseurl=http://mirrors.usc.edu/pub/linux/fedora/fedora/fedora/$releasever/$basearch/yum/unstable
#  http://fedora.mirror.sdv.fr/fedora/fedora/$releasever/$basearch/yum/unstable
#  http://fedora.quicknet.nl/fedora/fedora/$releasever/$basearch/yum/unstable
#  http://mirrors.kernel.org/fedora.us/fedora/fedora/$releasever/$basearch/yum/unstable
#  http://download.fedora.us/fedora/fedora/$releasever/$basearch/yum/unstable
#baseurl=http://download.fedora.us/fedora/fedora/$releasever/$basearch/yum/testing
#  http://fedora.quicknet.nl/fedora/fedora/$releasever/$basearch/yum/testing
#  http://fedora.mirror.sdv.fr/fedora/fedora/$releasever/$basearch/yum/testing
#  http://mirrors.kernel.org/fedora.us/fedora/fedora/$releasever/$basearch/yum/testing
#  http://mirrors.usc.edu/pub/linux/fedora/fedora/fedora/$releasever/$basearch/yum/testing
#baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/yum/stable
#baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/yum/unstable
#baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/yum/testing
# <http://prdownloads.sourceforge.net/jpackage/direct_download/1.5/generic/SRPMS.non-free>
# For the SRPMs, and <http://www.jpackage.org> for the general details.
#baseurl=http://aleron.dl.sourceforge.net/sourceforge/jpackage/direct_download/1.5/generic/free
#  http://heanet.dl.sourceforge.net/sourceforge/jpackage/direct_download/1.5/generic/free
#  http://umn.dl.sourceforge.net/sourceforge/jpackage/direct_download/1.5/generic/free
#baseurl=http://aleron.dl.sourceforge.net/sourceforge/jpackage/direct_download/1.5/fedora-$releasever/free
#  http://heanet.dl.sourceforge.net/sourceforge/jpackage/direct_download/1.5/fedora-$releasever/free
#  http://umn.dl.sourceforge.net/sourceforge/jpackage/direct_download/1.5/fedora-$releasever/free
#baseurl=http://ayo.freshrpms.net/fedora/linux/$releasever/$basearch/freshrpms/
#  http://ftp.us2.freshrpms.net/linux/freshrpms/ayo/fedora/linux/$releasever/$basearch/freshrpms/
#baseurl=http://dag.freshrpms.net/redhat/fc$releasever/en/$basearch/dag
#  http://ftp.heanet.ie/pub/freshrpms/pub/dag/redhat/fc$releasever/en/$basearch/dag
#baseurl=http://dries.studentenweb.org/yum/fedora/linux/$releasever/$basearch/dries
#baseurl=http://rpms.subpop.net/fedora/linux/$releasever/$basearch/production
#baseurl=http://newrpms.sunsite.dk/apt/redhat/en/$basearch/fc$releasever
#baseurl=http://apt.physik.fu-berlin.de/fedora/$releasever/en/$basearch/at-stable
#  http://ftp-stud.fht-esslingen.de/atrpms/download.atrpms.net/fedora/$releasever/en/$basearch/at-stable
#  http://wftp.tu-chemnitz.de/pub/linux/ATrpms/fedora/$releasever/en/$basearch/at-stable
#baseurl=http://ftp-stud.fht-esslingen.de/atrpms/download.atrpms.net/fedora/$releasever/en/$basearch/at-good
#  http://apt.physik.fu-berlin.de/fedora/$releasever/en/$basearch/at-good
#  http://wftp.tu-chemnitz.de/pub/linux/ATrpms/fedora/$releasever/en/$basearch/at-good
#baseurl=http://wftp.tu-chemnitz.de/pub/linux/ATrpms/fedora/$releasever/en/$basearch/at-testing
#  http://apt.physik.fu-berlin.de/fedora/$releasever/en/$basearch/at-testing
#  http://ftp-stud.fht-esslingen.de/atrpms/download.atrpms.net/fedora/$releasever/en/$basearch/at-testing
#baseurl=http://apt.physik.fu-berlin.de/fedora/$releasever/en/$basearch/at-bleeding
#  http://ftp-stud.fht-esslingen.de/atrpms/download.atrpms.net/fedora/$releasever/en/$basearch/at-bleeding
#  http://wftp.tu-chemnitz.de/pub/linux/ATrpms/fedora/$releasever/en/$basearch/at-bleeding
baseurl=http://macromedia.mplug.org/apt/fedora/$releasever
  http://sluglug.ucsc.edu/macromedia/apt/fedora/$releasever
  http://ruslug.rutgers.edu/macromedia/apt/fedora/$releasever
  http://macromedia.rediris.es/apt/fedora/$releasever
#baseurl=http://ftp.mozilla.org/pub/mozilla.org/mozilla/yum/SeaMonkey/releases/current/redhat/$releasever
#baseurl=http://fedoraproject.org/pre-extras/3/$basearch/
[root at localhost root]#
                                =====
I have to say that the display above seems amazingly long, compared to my
subjective impression of the whole file -- this takes three and a fraction
screens on my monitor, and the whole file is a tad over eleven.

-- 
Beartooth Implacable, Linux Evangelist & Gadfly
neo-redneck, curmudgeonly codger with FC1 & YDL 4.0
Pine 4.61, Pan 0.14.2; Privoxy 3.0.1; Opera 7.54, Firefox 1.0
Bear in mind that I have little idea what I am talking about.




From beartooth at adelphia.net  Sat Mar  5 22:01:32 2005
From: beartooth at adelphia.net (beartooth)
Date: Sat, 05 Mar 2005 17:01:32 -0500
Subject: Error: ... correct GPG keys installed?
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109873341.9846.447.camel@serendipity.dogma.lan>
	<pan.2005.03.03.19.43.46.910288@adelphia.net>
	<1109880833.9846.457.camel@serendipity.dogma.lan>
	<pan.2005.03.04.16.56.35.789396@adelphia.net>
	<1109967662.9846.511.camel@serendipity.dogma.lan>
Message-ID: <pan.2005.03.05.22.01.26.410537@adelphia.net>

On Fri, 04 Mar 2005 21:21:02 +0100, Alexander Dalloz wrote:

> This is
> 
> http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/perl-DateManip-5.42-0.fdr.2.a.1.noarch.rpm
> 
> from fedora.us. Which is a very different repository and uses its own
> GPG key.
> 
> rpm --import http://www.fedora.us/FEDORA-GPG-KEY

Jackpot and then some! I went and put the same yum.conf on another FC1
machine; got the same error; and did only the one key import, as above --
and it went swimmingly.

I presume that means fedora.us got hit first and gave yum all it wanted,
with no failover to anything else. Congrats to fedora.us!

Is there an easy way, or a list somewhere (like the list of mirrors), to
get other GPG keys? It'd be nice to have them.

There are quite a few repos *not* commented out in that yum.conf, which I
suppose it might hit if I happen to run yum at a time when fedora.us is
under heavy load -- and I notice that the format for the import command
for Dag Wieers, for instance, is not the same as for fedora.us ....

-- 
Beartooth Implacable, Linux Evangelist & Gadfly
neo-redneck, curmudgeonly codger with FC1&2  YDL 4.0
Pine 4.62, Pan 0.14.2; Privoxy 3.0.1; Opera 7.54, Firefox 1.0
Bear in mind that I have little idea what I am talking about.




From beartooth at adelphia.net  Sat Mar  5 22:06:06 2005
From: beartooth at adelphia.net (beartooth)
Date: Sat, 05 Mar 2005 17:06:06 -0500
Subject: VVDQ : keeping track ...
Message-ID: <pan.2005.03.05.22.06.05.980364@adelphia.net>

Very, *Very* Dumb Question : 

Is there a handy place to look, for those of us not all that active here,
to check from time to time which Fedoras have gone legacy and which are
still core? And when one that I have does go legacy (and the mirrors are
up -- another thing such a list might say), can I just go through the
yum.conf that I have for Fedora 1, and change all the 1's or fc1's to 2's
or fc2's to get a yum.conf for Fedora 2? Or would that create the mother
of all mare's nests?

-- 
Beartooth Implacable, Linux Evangelist & Gadfly
neo-redneck, curmudgeonly codger with FC1 & YDL 4.0
Pine 4.61, Pan 0.14.2; Privoxy 3.0.1; Opera 7.54, Firefox 1.0
Bear in mind that I have little idea what I am talking about.




From marcdeslauriers at videotron.ca  Mon Mar  7 12:59:09 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Mon, 07 Mar 2005 07:59:09 -0500
Subject: [FLSA-2005:1748] Updated subversion packages fix security issues
Message-ID: <422C501D.7000406@videotron.ca>

---------------------------------------------------------------------
                Fedora Legacy Update Advisory

Synopsis:          Updated subversion packages fix security issues
Advisory ID:       FLSA:1748
Issue date:        2005-03-07
Product:           Red Hat Linux
Keywords:          Bugfix
Cross references:  https://bugzilla.fedora.us/show_bug.cgi?id=1748
CVE Names:         CAN-2004-0397 CAN-2004-0413
---------------------------------------------------------------------


---------------------------------------------------------------------
1. Topic:

Updated subversion packages that fix several security issues are now
available.

Subversion is a concurrent version control system.

2. Relevant releases/architectures:

Red Hat Linux 9 - i386

3. Problem description:

Subversion versions up to 1.0.2 are vulnerable to a date parsing
vulnerability which can be abused to allow remote code execution on
Subversion servers and therefore could lead to a repository compromise.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0397 to this issue.

Subversion versions up to and including 1.0.4 have a potential Denial of
Service and Heap Overflow issue related to the parsing of strings in the
'svn://' family of access protocols. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2004-0413 to
this issue.

Users of subversion are advised to upgrade to these errata packages,
which contain backported patches correcting these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

http://bugzilla.fedora.us - bug #1748 - subversion advisories

6. RPMs required:

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/subversion-0.27.0-4.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/subversion-0.27.0-4.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/subversion-devel-0.27.0-4.legacy.i386.rpm

7. Verification:

SHA1 sum                                 Package Name
---------------------------------------------------------------------

9d08a9754083238df10241291832f90892f25e8f 
redhat/9/updates/i386/subversion-0.27.0-4.legacy.i386.rpm
68609fdd91802c5f3fb2f6d1a0fe9ba8e20ece39 
redhat/9/updates/i386/subversion-devel-0.27.0-4.legacy.i386.rpm
64c66197355f9424d18e62e589e4d377f4dd9b29 
redhat/9/updates/SRPMS/subversion-0.27.0-4.legacy.src.rpm

These packages are GPG signed by Fedora Legacy for security.  Our key is
available from http://www.fedoralegacy.org/about/security.php

You can verify each package with the following command:

     rpm --checksig -v <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the sha1sum with the following command:

     sha1sum <filename>

8. References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0397
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0413

9. Contact:

The Fedora Legacy security contact is <secnotice at fedoralegacy.org>. More
project details at http://www.fedoralegacy.org

---------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050307/ee957ea6/attachment.sig>

From marcdeslauriers at videotron.ca  Mon Mar  7 12:59:57 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Mon, 07 Mar 2005 07:59:57 -0500
Subject: [FLSA-2005:2344] Updated php packages fix security issues
Message-ID: <422C504D.5000507@videotron.ca>

---------------------------------------------------------------------
                Fedora Legacy Update Advisory

Synopsis:          Updated php packages fix security issues
Advisory ID:       FLSA:2344
Issue date:        2005-03-07
Product:           Red Hat Linux, Fedora Core
Keywords:          Bugfix
Cross references:  https://bugzilla.fedora.us/show_bug.cgi?id=2344
CVE Names:         CAN-2004-0958 CAN-2004-0959 CAN-2004-1018
                    CAN-2004-1019 CAN-2004-1065 CAN-2004-1392
---------------------------------------------------------------------


---------------------------------------------------------------------
1. Topic:

Updated php packages that fix various security issues are now available.

PHP is an HTML-embedded scripting language commonly used with the Apache
HTTP Web server.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386

3. Problem description:

An information disclosure bug was discovered in the parsing of "GPC"
variables in PHP (query strings or cookies, and POST form data). If
particular scripts used the values of the GPC variables, portions of the
memory space of an httpd child process could be revealed to the client.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0958 to this issue.

A file access bug was discovered in the parsing of "multipart/form-data"
forms, used by PHP scripts which allow file uploads. In particular
configurations, some scripts could allow a malicious client to upload
files to an arbitrary directory where the "apache" user has write
access. The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CAN-2004-0959 to this issue.

Flaws were found in shmop_write, pack, and unpack PHP functions. These
functions are not normally passed user supplied data, so would require a
malicious PHP script to be exploited. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2004-1018 to
this issue.

Flaws including possible information disclosure, double free, and
negative reference index array underflow were found in the
deserialization code of PHP. PHP applications may use the unserialize
function on untrusted user data, which could allow a remote attacker to
gain access to memory or potentially execute arbitrary code. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-1019 to this issue.

A flaw in the exif extension of PHP was found which lead to a stack
overflow. An attacker could create a carefully crafted image file in
such a way that if parsed by a PHP script using the exif extension it
could cause a crash or potentially execute arbitrary code. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-1065 to this issue.

A flaw in the PHP cURL functions allows remote attackers to bypass the
open_basedir setting and read arbitrary files via a file: URL argument
to the curl_init function. The Common Vulnerabilities and Exposures
project (cve.mitre.org) has assigned the name CAN-2004-1392 to this
issue.

Users of PHP should upgrade to these updated packages, which contain
fixes for these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

http://bugzilla.fedora.us - bug #2344 - multiple php vulns

6. RPMs required:

Red Hat Linux 7.3:

SRPM:
http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/php-4.1.2-7.3.14.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-4.1.2-7.3.14.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-devel-4.1.2-7.3.14.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-imap-4.1.2-7.3.14.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-ldap-4.1.2-7.3.14.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-manual-4.1.2-7.3.14.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-mysql-4.1.2-7.3.14.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-odbc-4.1.2-7.3.14.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-pgsql-4.1.2-7.3.14.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-snmp-4.1.2-7.3.14.legacy.i386.rpm

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/php-4.2.2-17.10.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/php-4.2.2-17.10.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-devel-4.2.2-17.10.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-imap-4.2.2-17.10.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-ldap-4.2.2-17.10.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-manual-4.2.2-17.10.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-mysql-4.2.2-17.10.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-odbc-4.2.2-17.10.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-pgsql-4.2.2-17.10.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-snmp-4.2.2-17.10.legacy.i386.rpm

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/php-4.3.10-1.1.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/php-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-devel-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-domxml-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-imap-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-ldap-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-mbstring-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-mysql-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-odbc-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-pgsql-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-snmp-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-xmlrpc-4.3.10-1.1.legacy.i386.rpm

7. Verification:

SHA1 sum                                 Package Name
---------------------------------------------------------------------

b88c0d83d4a9aeb974a6ee54ce66a27ecefa392a 
redhat/7.3/updates/i386/php-4.1.2-7.3.14.legacy.i386.rpm
48fd82779841a679e84e93f8ef1b612965acb342 
redhat/7.3/updates/i386/php-devel-4.1.2-7.3.14.legacy.i386.rpm
573aad4bab9f4f4399aedea743999020b3246614 
redhat/7.3/updates/i386/php-imap-4.1.2-7.3.14.legacy.i386.rpm
1a18d347e68013d29586f6a8db8283bdf7f6ff66 
redhat/7.3/updates/i386/php-ldap-4.1.2-7.3.14.legacy.i386.rpm
2a84f086225993aeccb0dfe2dd21ca8fcd78f26e 
redhat/7.3/updates/i386/php-manual-4.1.2-7.3.14.legacy.i386.rpm
d856fcc947e9386db2116f581cd0faf9efa5cf39 
redhat/7.3/updates/i386/php-mysql-4.1.2-7.3.14.legacy.i386.rpm
5621afdf4dd720ca24b489ccd115f6ead0b5343d 
redhat/7.3/updates/i386/php-odbc-4.1.2-7.3.14.legacy.i386.rpm
41bc8b4cf9c357c8030c09c4454c0e2173e0c523 
redhat/7.3/updates/i386/php-pgsql-4.1.2-7.3.14.legacy.i386.rpm
42bec2bd2e0f98fed8e01e82eef7a845c37020d2 
redhat/7.3/updates/i386/php-snmp-4.1.2-7.3.14.legacy.i386.rpm
8c6cf550cb6b6f4a75742120f56c6b77ff3d49e4 
redhat/7.3/updates/SRPMS/php-4.1.2-7.3.14.legacy.src.rpm
7fdeae44517dc2ef29fbb0480f9046fc6dadc8e3 
redhat/9/updates/i386/php-4.2.2-17.10.legacy.i386.rpm
e9244f6732eb2c83128d91e57439e7cc36c3c982 
redhat/9/updates/i386/php-devel-4.2.2-17.10.legacy.i386.rpm
054f45490faa2d6bc641b22bade7f3db92d07cde 
redhat/9/updates/i386/php-imap-4.2.2-17.10.legacy.i386.rpm
76ade25210bb37b4757b535d48de39e8c2dec622 
redhat/9/updates/i386/php-ldap-4.2.2-17.10.legacy.i386.rpm
53d0e83c9b10e9d84e0150c9dbdb70f4df3a930a 
redhat/9/updates/i386/php-manual-4.2.2-17.10.legacy.i386.rpm
81ac7899358407bbd2c38baf7547136413970372 
redhat/9/updates/i386/php-mysql-4.2.2-17.10.legacy.i386.rpm
cceed4ce195fa9ff864eb6561b7bfb6297eb5bff 
redhat/9/updates/i386/php-odbc-4.2.2-17.10.legacy.i386.rpm
839c239b525265df7abaeac1c5f0c08092c74944 
redhat/9/updates/i386/php-pgsql-4.2.2-17.10.legacy.i386.rpm
b1cd0eb61b109a2b5da15791b8781806b44c7efc 
redhat/9/updates/i386/php-snmp-4.2.2-17.10.legacy.i386.rpm
fe9529ca28ff2663a9b520fd5e774cf931e0b135 
redhat/9/updates/SRPMS/php-4.2.2-17.10.legacy.src.rpm
dd0daa7c3d6b4f491605e698c39cb451edff50ba 
fedora/1/updates/i386/php-4.3.10-1.1.legacy.i386.rpm
c07635eca5d2ce4f1972c5faf3e14f4c00a19f2d 
fedora/1/updates/i386/php-devel-4.3.10-1.1.legacy.i386.rpm
2658aabd4ebe409b0b9532baf0894abfe15c0f38 
fedora/1/updates/i386/php-domxml-4.3.10-1.1.legacy.i386.rpm
b38d0ef81f4ccc1ef914bdeb4077461d4dba2d7b 
fedora/1/updates/i386/php-imap-4.3.10-1.1.legacy.i386.rpm
e8d7d69f35641f915edba0eb9c5915db60e318d5 
fedora/1/updates/i386/php-ldap-4.3.10-1.1.legacy.i386.rpm
f9a609b45b56e028080246ea7df8a53d1e0c33b7 
fedora/1/updates/i386/php-mbstring-4.3.10-1.1.legacy.i386.rpm
f34d4ab35fc29149a8c8f84140940c9470356415 
fedora/1/updates/i386/php-mysql-4.3.10-1.1.legacy.i386.rpm
71c362c35b2368348b56d8cd5f7c03812f7b7aa2 
fedora/1/updates/i386/php-odbc-4.3.10-1.1.legacy.i386.rpm
de668bafb64e2f7cb8e3d1add11e8037159ce90d 
fedora/1/updates/i386/php-pgsql-4.3.10-1.1.legacy.i386.rpm
d2bc37081e2633c0cbd721b24cbbeadffc0196be 
fedora/1/updates/i386/php-snmp-4.3.10-1.1.legacy.i386.rpm
1538dab5f7b07a29191f459441478a4c9cc2c11e 
fedora/1/updates/i386/php-xmlrpc-4.3.10-1.1.legacy.i386.rpm
125b673172ebeb9cf0bdefe5adc0060ae10d3c9d 
fedora/1/updates/SRPMS/php-4.3.10-1.1.legacy.src.rpm

These packages are GPG signed by Fedora Legacy for security.  Our key is
available from http://www.fedoralegacy.org/about/security.php

You can verify each package with the following command:

     rpm --checksig -v <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the sha1sum with the following command:

     sha1sum <filename>

8. References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0958
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0959
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1018
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1019
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1065
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1392

9. Contact:

The Fedora Legacy security contact is <secnotice at fedoralegacy.org>. More
project details at http://www.fedoralegacy.org

---------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050307/56690ee8/attachment.sig>

From dom at earth.li  Mon Mar  7 17:09:18 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Mon, 7 Mar 2005 17:09:18 +0000
Subject: mirror configuration tweak?
Message-ID: <20050307170918.GZ987@tirian.magd.ox.ac.uk>

https://bugzilla.fedora.us/show_bug.cgi?id=2281

Perhaps we should add this symlink to the download server?

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



From sheltren at cs.ucsb.edu  Mon Mar  7 17:18:03 2005
From: sheltren at cs.ucsb.edu (Jeff Sheltren)
Date: Mon, 07 Mar 2005 09:18:03 -0800
Subject: mirror configuration tweak?
In-Reply-To: <20050307170918.GZ987@tirian.magd.ox.ac.uk>
Message-ID: <BE51CCCB.1DDDA%sheltren@cs.ucsb.edu>

On 3/7/05 9:09 AM, "Dominic Hargreaves" <dom at earth.li> wrote:

> https://bugzilla.fedora.us/show_bug.cgi?id=2281
> 
> Perhaps we should add this symlink to the download server?

Sounds like a good idea to me.  It *shouldn't* break anything, and would be
more consistent with newer FC releases.

-Jeff




From cave.dnb at tiscali.fr  Mon Mar  7 19:10:37 2005
From: cave.dnb at tiscali.fr (nigel henry)
Date: Mon, 7 Mar 2005 19:10:37 +0000
Subject: Error: ... correct GPG keys installed?
In-Reply-To: <pan.2005.03.05.22.01.26.410537@adelphia.net>
References: <pan.2005.02.26.20.29.14.69654@adelphia.net>
	<1109967662.9846.511.camel@serendipity.dogma.lan>
	<pan.2005.03.05.22.01.26.410537@adelphia.net>
Message-ID: <200503071910.37265.cave.dnb@tiscali.fr>

On Saturday 05 Mar 2005 10:01 pm, beartooth wrote:
> On Fri, 04 Mar 2005 21:21:02 +0100, Alexander Dalloz wrote:
> > This is
> >
> > http://download.fedora.us/fedora/fedora/1/i386/RPMS.stable/perl-DateManip
> >-5.42-0.fdr.2.a.1.noarch.rpm
> >
> > from fedora.us. Which is a very different repository and uses its own
> > GPG key.
> >
> > rpm --import http://www.fedora.us/FEDORA-GPG-KEY
>
> Jackpot and then some! I went and put the same yum.conf on another FC1
> machine; got the same error; and did only the one key import, as above --
> and it went swimmingly.
>
> I presume that means fedora.us got hit first and gave yum all it wanted,
> with no failover to anything else. Congrats to fedora.us!
>
> Is there an easy way, or a list somewhere (like the list of mirrors), to
> get other GPG keys? It'd be nice to have them.
>
> There are quite a few repos *not* commented out in that yum.conf, which I
> suppose it might hit if I happen to run yum at a time when fedora.us is
> under heavy load -- and I notice that the format for the import command
> for Dag Wieers, for instance, is not the same as for fedora.us ....

Hi beartooth. The only thing I would say for what it's worth is be carefull 
about conflicts between different repositories. With FC1 it won't be a 
problem as no-one else is providing updates for the system. But FC2 for 
instance might be a bit different as there are repositories all over the 
place for updates. For instance. I added the dag wieers repository to my apt 
sources.list that I use for planetccrma music software updates and the FC2 
ones as well. Then did an apt-get update. There were a few bits from dag 
wieers for updating the system including apt. I presumed planetccrma might 
have missed em, so updated them. Problems! The updated apt from dag wieers 
had also created a new sources.list with dag wieers repositories and about 5 
others including freshrpms. No sign of the planetccrma repositories, and the 
original sources.list with the planet repositories had disappeared! I got it 
back in place, but all was a bit annoying. You might have an app installed 
from repository "x" and get updates for it from them. You then add a new 
repository to the list which happens to have the same app. You do a yum 
update and the new repository proceeds to update your app from repository 
"x". I'm not saying you will get conflicts, but just be aware that they can 
occur. Glad you got the legacy key installed. Nigel.



From kelson at speed.net  Mon Mar  7 18:37:16 2005
From: kelson at speed.net (Kelson)
Date: Mon, 07 Mar 2005 10:37:16 -0800
Subject: VVDQ : keeping track ...
In-Reply-To: <pan.2005.03.05.22.06.05.980364@adelphia.net>
References: <pan.2005.03.05.22.06.05.980364@adelphia.net>
Message-ID: <422C9F5C.8060303@speed.net>

beartooth wrote:
> Is there a handy place to look, for those of us not all that active here,
> to check from time to time which Fedoras have gone legacy and which are
> still core?

Hmm, I don't think so.  There's a list of releases with advisories, but 
it includes RH 7.2 and RH 8.0 (and a big "support for RH7.2 and RH8 is 
suspended" notice)

A clear list is something to add, though, and I'll create a page on the 
wiki today if I can figure out how in a reasonable amount of time (and 
if I don't find the info already there in the process).  Really, this 
should be a sidebar on the Fedora Legacy home page.  Just "Currently 
supported: Fedora Core 1, Red Hat 9, Red Hat 7.3."

However, Fedora Core's policy is to never support more than one release 
back, so you can go to http://fedora.redhat.com/ and see which one is 
current.  One back *might* be supported, but two back will *not* be. 
For instance, right now FC3 is current, and FC2 is deprecated.  FC2 is 
still core for a couple more weeks, at which point it will be handed off 
to Legacy.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>



From kelson at speed.net  Mon Mar  7 19:02:35 2005
From: kelson at speed.net (Kelson)
Date: Mon, 07 Mar 2005 11:02:35 -0800
Subject: VVDQ : keeping track ...
In-Reply-To: <422C9F5C.8060303@speed.net>
References: <pan.2005.03.05.22.06.05.980364@adelphia.net>
	<422C9F5C.8060303@speed.net>
Message-ID: <422CA54B.6010903@speed.net>

Kelson wrote:
> beartooth wrote:
> 
>> Is there a handy place to look, for those of us not all that active here,
>> to check from time to time which Fedoras have gone legacy and which are
>> still core?
> 
> Hmm, I don't think so.  There's a list of releases with advisories, but 
> it includes RH 7.2 and RH 8.0 (and a big "support for RH7.2 and RH8 is 
> suspended" notice)
> 
> A clear list is something to add, though, and I'll create a page on the 
> wiki today if I can figure out how in a reasonable amount of time (and 
> if I don't find the info already there in the process).  Really, this 
> should be a sidebar on the Fedora Legacy home page.  Just "Currently 
> supported: Fedora Core 1, Red Hat 9, Red Hat 7.3."

Never mind, I just realized all the wiki stuff is aimed at developers.

Who's in charge of the website, and how do I go about 
submitting/suggesting a change?

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>



From jkeating at j2solutions.net  Mon Mar  7 19:14:10 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 07 Mar 2005 11:14:10 -0800
Subject: VVDQ : keeping track ...
In-Reply-To: <422CA54B.6010903@speed.net>
References: <pan.2005.03.05.22.06.05.980364@adelphia.net>
	<422C9F5C.8060303@speed.net>  <422CA54B.6010903@speed.net>
Message-ID: <1110222850.12887.115.camel@jkeating2.hq.pogolinux.com>

On Mon, 2005-03-07 at 11:02 -0800, Kelson wrote:
> Never mind, I just realized all the wiki stuff is aimed at developers.
> 
> Who's in charge of the website, and how do I go about 
> submitting/suggesting a change?

That would be Eric Rostetter.  Propose changes on the list so that the
community at large can approve them.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From kelson at speed.net  Mon Mar  7 19:58:05 2005
From: kelson at speed.net (Kelson)
Date: Mon, 07 Mar 2005 11:58:05 -0800
Subject: VVDQ : keeping track ...
In-Reply-To: <1110222850.12887.115.camel@jkeating2.hq.pogolinux.com>
References: <pan.2005.03.05.22.06.05.980364@adelphia.net>	<422C9F5C.8060303@speed.net>
	<422CA54B.6010903@speed.net>
	<1110222850.12887.115.camel@jkeating2.hq.pogolinux.com>
Message-ID: <422CB24D.6070501@speed.net>

Jesse Keating wrote:
> On Mon, 2005-03-07 at 11:02 -0800, Kelson wrote:
>>Who's in charge of the website, and how do I go about 
>>submitting/suggesting a change?
> 
> That would be Eric Rostetter.  Propose changes on the list so that the
> community at large can approve them.

OK, I'd like to suggest adding something like this to the sidebar on the 
home page, either right above or right below the News section:

     <div class="fl-side-right-content">
     <h1>Current Releases</h1>

     <p>Releases currently supported by Fedora Legacy.</p>
     <ul>
         <li>Red Hat Linux 7.3</li>
         <li>Red Hat Linux 9</li>
	<li>Fedora Core 1</li>
     </ul>
     </div>

This would be updated whenever FL picks up or drops a release, so we 
would add Fedora Core 2 in a few weeks.  We could also list pending 
releases, like "<li>Fedora Core 2 (beginning March 21, 2005)</li>" 
(dropping the date once we reach it) and deprecated releases, like 
"<li>Fedora Core 1 (until such-and-such)</li>" once a date has been 
chosen to start/stop support.

The idea is that at a glance, someone who is unfamiliar with the project 
will know immediately which releases can be brought/kept up using FL, 
and a year or two down the road someone who has fired-and-forgotten a 
config with, say, FC1 will realize immediately why there haven't been 
any updates since early 2006 (or whenever).

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>



From ingo at auroralinux.org  Mon Mar  7 20:14:24 2005
From: ingo at auroralinux.org (Ingo T. Storm)
Date: Mon, 07 Mar 2005 21:14:24 +0100
Subject: VVDQ : keeping track ...
In-Reply-To: <422CB24D.6070501@speed.net>
References: <pan.2005.03.05.22.06.05.980364@adelphia.net>	<422C9F5C.8060303@speed.net>	<422CA54B.6010903@speed.net>	<1110222850.12887.115.camel@jkeating2.hq.pogolinux.com>
	<422CB24D.6070501@speed.net>
Message-ID: <422CB620.5070900@auroralinux.org>

Kelson schrieb:
> OK, I'd like to suggest adding something like this to the sidebar on the 
> home page, either right above or right below the News section:

agreed, except that that I would place it between "News" and "Project 
Support".

While we're at suggestione: I suggest to add a comment to the fl default 
yum.conf that "strongly suggests" to subscribe to fl-announce so that no 
one realizes one exploit too late that her platform isn't supported any 
longer.

regards,
IngoTee



From guallar at easternrad.com  Mon Mar  7 20:58:04 2005
From: guallar at easternrad.com (Josep L. Guallar-Esteve)
Date: Mon, 7 Mar 2005 15:58:04 -0500
Subject: VVDQ : keeping track ...
In-Reply-To: <422CB24D.6070501@speed.net>
References: <pan.2005.03.05.22.06.05.980364@adelphia.net>
	<1110222850.12887.115.camel@jkeating2.hq.pogolinux.com>
	<422CB24D.6070501@speed.net>
Message-ID: <200503071558.06717.guallar@easternrad.com>

On Monday 07 March 2005 14:58, Kelson wrote:
> OK, I'd like to suggest adding something like this to the sidebar on the
> home page, either right above or right below the News section:
>
> ? ? ?<div class="fl-side-right-content">
> ? ? ?<h1>Current Releases</h1>
>
> ? ? ?<p>Releases currently supported by Fedora Legacy.</p>
> ? ? ?<ul>
> ? ? ? ? ?<li>Red Hat Linux 7.3</li>
> ? ? ? ? ?<li>Red Hat Linux 9</li>
> ????????<li>Fedora Core 1</li>
> ? ? ?</ul>
> ? ? ?</div>
>
> This would be updated whenever FL picks up or drops a release,

Makes a lot of sense to me.

I welcome and support this addition.


Regards,
Josep
-- 
Josep L. Guallar-Esteve		Eastern Radiologists, Inc.
Systems and PACS Administration  http://www.easternrad.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050307/dd1cc7ef/attachment.sig>

From info at hostinthebox.net  Mon Mar  7 21:11:59 2005
From: info at hostinthebox.net (dan)
Date: Mon, 07 Mar 2005 14:11:59 -0700
Subject: Questions about creating RPMs
Message-ID: <422CC39F.4090108@hostinthebox.net>

Hello, all -

I know that a lot of you guys are making Fedora Legacy RPMs, and I was 
curious as to if you use some sort of template in vi or *gasp* emacs or 
something of the like.  I've been doing this by hand for a bit now, and 
it's a lot of work.  Surely there's a simplified way.

I read somewhere that emacs has a template for creating spec files, but 
was not entirely sure if this is what you guys used.

In all reality, I should just go get a book instead of being lazy, but I 
thought it might be good to ask.

Thanks!
-dant



From john at pybus.org  Mon Mar  7 21:52:43 2005
From: john at pybus.org (John Pybus)
Date: Mon, 07 Mar 2005 21:52:43 +0000
Subject: VVDQ : keeping track ...
In-Reply-To: <422CB620.5070900@auroralinux.org>
References: <pan.2005.03.05.22.06.05.980364@adelphia.net>	<422C9F5C.8060303@speed.net>	<422CA54B.6010903@speed.net>	<1110222850.12887.115.camel@jkeating2.hq.pogolinux.com>	<422CB24D.6070501@speed.net>
	<422CB620.5070900@auroralinux.org>
Message-ID: <422CCD2B.40400@pybus.org>

Ingo T. Storm wrote:
> Kelson schrieb:
> 
>> OK, I'd like to suggest adding something like this to the sidebar on 
>> the home page, either right above or right below the News section:
> 
> 
> agreed, except that that I would place it between "News" and "Project 
> Support".
> 
> While we're at suggestione: I suggest to add a comment to the fl default 
> yum.conf that "strongly suggests" to subscribe to fl-announce so that no 
> one realizes one exploit too late that her platform isn't supported any 
> longer.

Alternatively (or in addition) Fedora Legacy could undertake to release 
on end of support for any OS one final update, to a package such as 
redhat-release, which contains a post-install script to alter the 
message of the day, and write a suitably noticeable message to syslog.

John



From kelson at speed.net  Mon Mar  7 22:28:20 2005
From: kelson at speed.net (Kelson)
Date: Mon, 07 Mar 2005 14:28:20 -0800
Subject: Questions about creating RPMs
In-Reply-To: <422CC39F.4090108@hostinthebox.net>
References: <422CC39F.4090108@hostinthebox.net>
Message-ID: <422CD584.2060000@speed.net>

dan wrote:
> I know that a lot of you guys are making Fedora Legacy RPMs, and I was 
> curious as to if you use some sort of template in vi or *gasp* emacs or 
> something of the like.  I've been doing this by hand for a bit now, and 
> it's a lot of work.  Surely there's a simplified way.

I haven't worked on any of the RPMS for FL (though I think I noticed 
guidelines of some sort on the wiki), but when I build my own I 
frequently start with the .spec file in the SRPM for an earlier version.

It often takes some tweaking, especially if files get moved or replaced 
between versions, but it does simplify the process immensely.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>



From info at hostinthebox.net  Mon Mar  7 23:22:24 2005
From: info at hostinthebox.net (dan)
Date: Mon, 07 Mar 2005 16:22:24 -0700
Subject: Questions about creating RPMs
In-Reply-To: <422CD584.2060000@speed.net>
References: <422CC39F.4090108@hostinthebox.net> <422CD584.2060000@speed.net>
Message-ID: <422CE230.8090500@hostinthebox.net>

Kelson wrote:
> dan wrote:
> 
>> I know that a lot of you guys are making Fedora Legacy RPMs, and I was 
>> curious as to if you use some sort of template in vi or *gasp* emacs 
>> or something of the like.  I've been doing this by hand for a bit now, 
>> and it's a lot of work.  Surely there's a simplified way.
> 
> 
> I haven't worked on any of the RPMS for FL (though I think I noticed 
> guidelines of some sort on the wiki), but when I build my own I 
> frequently start with the .spec file in the SRPM for an earlier version.
> 
> It often takes some tweaking, especially if files get moved or replaced 
> between versions, but it does simplify the process immensely.
> 

Yea, I do that, as well.  But I've never been able to make one from 
scratch.  I lack skill, I suppose.

Again, sorry to waste all your time, this is definately something that I 
should just RTFM on.  Thanks anyway though.

-dant



From michal at harddata.com  Mon Mar  7 23:46:27 2005
From: michal at harddata.com (Michal Jaegermann)
Date: Mon, 7 Mar 2005 16:46:27 -0700
Subject: Questions about creating RPMs
In-Reply-To: <422CE230.8090500@hostinthebox.net>;
	from info@hostinthebox.net on Mon, Mar 07, 2005 at 04:22:24PM
	-0700
References: <422CC39F.4090108@hostinthebox.net> <422CD584.2060000@speed.net>
	<422CE230.8090500@hostinthebox.net>
Message-ID: <20050307164627.B13535@mail.harddata.com>

On Mon, Mar 07, 2005 at 04:22:24PM -0700, dan wrote:
> > 
> >> I've been doing this by hand for a bit now, 
> >> and it's a lot of work.  Surely there's a simplified way.
....
> 
> Yea, I do that, as well.  But I've never been able to make one from 
> scratch.

rpm-spec-mode.el, at least a version which is used in the current
FC releases, will write you a skeleton spec file from scratch if
you are starting with something which does not exist.

You can use that with earlier emacs versions even if it comes
in emacs-el-21.3-21.FC3 package (.elc in emacs-common-21.3-21.FC3
but you may prefer to ask _your_ emacs to compile it even if
you want to bother with that; with current machines startup time
savings are negligible).

   Michal



From dom at earth.li  Tue Mar  8 00:09:45 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Tue, 8 Mar 2005 00:09:45 +0000
Subject: VVDQ : keeping track ...
In-Reply-To: <422CCD2B.40400@pybus.org>
References: <pan.2005.03.05.22.06.05.980364@adelphia.net>
	<422C9F5C.8060303@speed.net> <422CA54B.6010903@speed.net>
	<1110222850.12887.115.camel@jkeating2.hq.pogolinux.com>
	<422CB24D.6070501@speed.net> <422CB620.5070900@auroralinux.org>
	<422CCD2B.40400@pybus.org>
Message-ID: <20050308000945.GA987@tirian.magd.ox.ac.uk>

On Mon, Mar 07, 2005 at 09:52:43PM +0000, John Pybus wrote:

> Alternatively (or in addition) Fedora Legacy could undertake to release 
> on end of support for any OS one final update, to a package such as 
> redhat-release, which contains a post-install script to alter the 
> message of the day, and write a suitably noticeable message to syslog.

No, I don't think so. One is far too intrusive, the other likely to be
ignored.

I *presume* that our existence is announced on the relevant FC mailing
lists at the time of a release going EOL. That should be sufficient.

*However* it is important that when said users get pointed at our web
site the situation is clear, and I agree with the previously suggested
changes. If someone has time they could perhaps even whip up a summary
page for FC? users which has all the information they'd need on one
page.

Cheers,

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



From dom at earth.li  Tue Mar  8 00:12:35 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Tue, 8 Mar 2005 00:12:35 +0000
Subject: Questions about creating RPMs
In-Reply-To: <422CE230.8090500@hostinthebox.net>
References: <422CC39F.4090108@hostinthebox.net> <422CD584.2060000@speed.net>
	<422CE230.8090500@hostinthebox.net>
Message-ID: <20050308001234.GB987@tirian.magd.ox.ac.uk>

On Mon, Mar 07, 2005 at 04:22:24PM -0700, dan wrote:

> Again, sorry to waste all your time, this is definately something that I 
> should just RTFM on.  Thanks anyway though.

<http://www.tldp.org/HOWTO/RPM-HOWTO/index.html> is probably still a
useful FM, though it doesn't seem to have been updated for a while.

Cheers,

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



From rostetter at mail.utexas.edu  Tue Mar  8 00:14:07 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Mon,  7 Mar 2005 18:14:07 -0600
Subject: VVDQ : keeping track ...
In-Reply-To: <1110222850.12887.115.camel@jkeating2.hq.pogolinux.com>
References: <pan.2005.03.05.22.06.05.980364@adelphia.net>
	<422C9F5C.8060303@speed.net> <422CA54B.6010903@speed.net>
	<1110222850.12887.115.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1110240847.ccbbec8a4bbac@mail.ph.utexas.edu>

Quoting Jesse Keating <jkeating at j2solutions.net>:

> On Mon, 2005-03-07 at 11:02 -0800, Kelson wrote:
> > Never mind, I just realized all the wiki stuff is aimed at developers.

No, the wiki is meant for everyone.  One of its (many) intended functions
is to be a place people can develop pages for the web site, to be transfered
to the web site when everyone agrees they are ready.

> > Who's in charge of the website, and how do I go about
> > submitting/suggesting a change?
> 
> That would be Eric Rostetter.  Propose changes on the list so that the
> community at large can approve them.

Or in the wiki, and ask the mailing list for approval, etc.

> --
> Jesse Keating RHCE      (geek.j2solutions.net)
> Fedora Legacy Team      (www.fedoralegacy.org)
> GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
> 
> Was I helpful?  Let others know:
>  http://svcs.affero.net/rm.php?r=jkeating
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
> 


-- 
Eric Rostetter



From marcdeslauriers at videotron.ca  Tue Mar  8 03:19:52 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Mon, 07 Mar 2005 22:19:52 -0500
Subject: Fedora Legacy Test Update Notification: postgresql
Message-ID: <422D19D8.8070202@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2260
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2260
2005-03-07
---------------------------------------------------------------------

Name        : postgresql
Versions    : rh7.3: postgresql-7.2.7-1.2.legacy
Versions    : rh9: postgresql-7.3.9-0.90.2.legacy
Versions    : fc1: postgresql-7.3.9-1.2.legacy
Summary     : PostgreSQL client programs and libraries.
Description :
PostgreSQL is an advanced Object-Relational database management system
(DBMS) that supports almost all SQL constructs, including
transactions, subselects, and user-defined types and functions. The
postgresql package includes the client programs and libraries that you
need to access a PostgreSQL DBMS server.

---------------------------------------------------------------------
Update Information:

Updated PostgreSQL packages to fix various security flaws are now available.

PostgreSQL is an advanced Object-Relational database management system
(DBMS).

Trustix has identified improper temporary file usage in the
make_oidjoins_check script. It is possible that an attacker could
overwrite arbitrary file contents as the user running the
make_oidjoins_check script. This script has been removed from the RPM file
since it has no use to ordinary users. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2004-0977 to
this issue.

A flaw in the LOAD command in PostgreSQL was discovered. A local user
could use this flaw to load arbitrary shared librarys and therefore execute
arbitrary code, gaining the privileges of the PostgreSQL server. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned
the name CAN-2005-0227 to this issue.

A permission checking flaw in PostgreSQL was discovered. A local user
could bypass the EXECUTE permission check for functions by using the CREATE
AGGREGATE command. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2005-0244 to this issue.

Multiple buffer overflows were found in PL/PgSQL. A database user who has
permissions to create plpgsql functions could trigger this flaw which could
lead to arbitrary code execution, gaining the privileges of the PostgreSQL
server. The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the names CAN-2005-0245 and CAN-2005-0247 to these issues.

A flaw in the integer aggregator (intagg) contrib module for PostgreSQL was
found. A user could create carefully crafted arrays and cause a denial of
service (crash). The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2005-0246 to this issue.

Users of PostgreSQL are advised to update to these erratum packages which
are not vulnerable to these issues.

---------------------------------------------------------------------
Changelogs

rh73:
* Mon Mar 07 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7.2.7-1.2.legacy
- Added missing XFree86-devel, bison, libtermcap-devel, flex
   perl-SGMLSpm, openjade, e2fsprogs-devel and docbook-utils BuildRequires

* Fri Mar 04 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7.2.7-1.1.legacy
- Update to 7.2.7 to fix multiple security issues (CAN-2005-0227,
   CAN-2005-0245, and other issues)
- Patch additional buffer overruns in plpgsql (CAN-2005-0247)
- Remove contrib/oidjoins stuff from installed fileset; it's of no use
   to ordinary users and has a security issue (RH bugs 136300, 136301)

rh9:
* Mon Mar 07 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7.3.9-1.2.legacy
- Added missing autoconf, libtermcap-devel, perl-SGMLSpm, docbook-utils
   and docbook-style-dsssl to BuildRequires

* Fri Mar 04 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7.3.9-1.1.legacy
- Update to PostgreSQL 7.3.9 (fixes CAN-2005-0227, CAN-2005-0244,
   CAN-2005-0245, CAN-2005-0246, CAN-2004-0977 and other issues).
- Patch additional buffer overruns in plpgsql (CAN-2005-0247)
- Remove contrib/oidjoins stuff from installed fileset; it's of no use
   to ordinary users and has a security issue (RH bugs 136300, 136301)

fc1:
* Mon Mar 07 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7.3.9-1.2.legacy
- Added missing libtermcap-devel, perl-SGMLSpm, openjade, docbook-utils
   and docbook-style-dsssl to BuildRequires

* Fri Mar 04 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7.3.9-1.1.legacy
- Rebuilt as Fedora Legacy security update for FC1

* Tue Feb 08 2005 Tom Lane <tgl at redhat.com> 7.3.9-2
- Patch additional buffer overruns in plpgsql (CAN-2005-0247)

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
d31c189c8a7deff6956075bf77e2b1d65ec5c4a7 
redhat/7.3/updates-testing/i386/postgresql-7.2.7-1.2.legacy.i386.rpm
2f0d1bf43ce424777839a4114c1586de17003028 
redhat/7.3/updates-testing/i386/postgresql-contrib-7.2.7-1.2.legacy.i386.rpm
3c8ca3b49b600ee328d376509ba2fa81178bc785 
redhat/7.3/updates-testing/i386/postgresql-devel-7.2.7-1.2.legacy.i386.rpm
69f068253ca62dbfecf102e4599ad592fe07d654 
redhat/7.3/updates-testing/i386/postgresql-docs-7.2.7-1.2.legacy.i386.rpm
0aef7d8c5eaa0f9acbbf6bbdb9aa325ff993094c 
redhat/7.3/updates-testing/i386/postgresql-jdbc-7.2.7-1.2.legacy.i386.rpm
4ddd20835495bf19a00665136b3e7634e3e29da4 
redhat/7.3/updates-testing/i386/postgresql-libs-7.2.7-1.2.legacy.i386.rpm
11a5ef1ad11f2cbd11344aa225c4685ecffe56c1 
redhat/7.3/updates-testing/i386/postgresql-odbc-7.2.7-1.2.legacy.i386.rpm
5cafe5600b825fcbf96eebc390ac0f2024b2a2be 
redhat/7.3/updates-testing/i386/postgresql-perl-7.2.7-1.2.legacy.i386.rpm
a00ed6283f7b0b4878be4a5d33c4d08c6cecd032 
redhat/7.3/updates-testing/i386/postgresql-python-7.2.7-1.2.legacy.i386.rpm
022b23b4f4f7942220a8ca069b739089873685b2 
redhat/7.3/updates-testing/i386/postgresql-server-7.2.7-1.2.legacy.i386.rpm
77156886ec28350b6dffef06f96fcb3ee1ee7ebf 
redhat/7.3/updates-testing/i386/postgresql-tcl-7.2.7-1.2.legacy.i386.rpm
2c3cc238af77cee13a342c677c965c5d57c34bb9 
redhat/7.3/updates-testing/i386/postgresql-test-7.2.7-1.2.legacy.i386.rpm
f150672bd8473dc450010b436e557a46761f5c57 
redhat/7.3/updates-testing/i386/postgresql-tk-7.2.7-1.2.legacy.i386.rpm
35222d526cd08e720a50d5f441a152fc6d93056f 
redhat/7.3/updates-testing/SRPMS/postgresql-7.2.7-1.2.legacy.src.rpm

rh9:
97c1e38c06d6bb16a76e346aad2a9ae9f4dbe4de 
redhat/9/updates-testing/i386/postgresql-7.3.9-0.90.2.legacy.i386.rpm
44dc64014d89dd84cb7dbc7077adcb0b8d382233 
redhat/9/updates-testing/i386/postgresql-contrib-7.3.9-0.90.2.legacy.i386.rpm
12fea917971b79931ab833c7725e2fed9ee737f5 
redhat/9/updates-testing/i386/postgresql-devel-7.3.9-0.90.2.legacy.i386.rpm
db0d341829ca4d29dfefa049939efea2f0a7b966 
redhat/9/updates-testing/i386/postgresql-docs-7.3.9-0.90.2.legacy.i386.rpm
882789ef9a838332b16477f4c217c9c61517ac97 
redhat/9/updates-testing/i386/postgresql-jdbc-7.3.9-0.90.2.legacy.i386.rpm
9247cee701af231b2c5a29d880c347a2a9d99399 
redhat/9/updates-testing/i386/postgresql-libs-7.3.9-0.90.2.legacy.i386.rpm
7afd9c0344c6b340d77fd74be9ba2f7b078d7a8a 
redhat/9/updates-testing/i386/postgresql-pl-7.3.9-0.90.2.legacy.i386.rpm
11889c69f5ecafcbf8d75905d8452ae3a8f8227f 
redhat/9/updates-testing/i386/postgresql-python-7.3.9-0.90.2.legacy.i386.rpm
1446eb258819fb54beb7c4cafd53ad828b445eab 
redhat/9/updates-testing/i386/postgresql-server-7.3.9-0.90.2.legacy.i386.rpm
9d367f4e478199a6d186633f302c706ba2a6dbd6 
redhat/9/updates-testing/i386/postgresql-tcl-7.3.9-0.90.2.legacy.i386.rpm
8c06644a98389f11fa1a5a13f5a4d6c9558b8d0f 
redhat/9/updates-testing/i386/postgresql-test-7.3.9-0.90.2.legacy.i386.rpm
7855eeced400cfeaf85b478c69810099eb304826 
redhat/9/updates-testing/SRPMS/postgresql-7.3.9-0.90.2.legacy.src.rpm

fc1:
e41bd8377a22b935f44202ddc785fc9185355234 
fedora/1/updates-testing/i386/postgresql-7.3.9-1.2.legacy.i386.rpm
efab40afd8fe5c92a7d68a5a41d01fcec96430c6 
fedora/1/updates-testing/i386/postgresql-contrib-7.3.9-1.2.legacy.i386.rpm
9044550eed20628c22f4f75bb13afcddfd0d724a 
fedora/1/updates-testing/i386/postgresql-devel-7.3.9-1.2.legacy.i386.rpm
8c689dc13b2be91d97a235a389f85f615d1d1ee6 
fedora/1/updates-testing/i386/postgresql-docs-7.3.9-1.2.legacy.i386.rpm
2da174ac3fd08fa4e5dda831054d1e541f7226fb 
fedora/1/updates-testing/i386/postgresql-jdbc-7.3.9-1.2.legacy.i386.rpm
d6a0eb0d12ebc73b5fde3bd45e6eb9061f56ca00 
fedora/1/updates-testing/i386/postgresql-libs-7.3.9-1.2.legacy.i386.rpm
a1bccc43dffd3bbb0bcd1351f4b75965f8e24e6d 
fedora/1/updates-testing/i386/postgresql-pl-7.3.9-1.2.legacy.i386.rpm
4a4d1bf5cfa876b0303a4eefb4df4aea7f90cea3 
fedora/1/updates-testing/i386/postgresql-python-7.3.9-1.2.legacy.i386.rpm
62e0287827577a799f586b0815cbbe5544952207 
fedora/1/updates-testing/i386/postgresql-server-7.3.9-1.2.legacy.i386.rpm
c993c8888856a89603116de70a8f6f5de8422c7a 
fedora/1/updates-testing/i386/postgresql-tcl-7.3.9-1.2.legacy.i386.rpm
766dd53d0ef9761c986373f7c9626ecb85635893 
fedora/1/updates-testing/i386/postgresql-test-7.3.9-1.2.legacy.i386.rpm
993c2134e2a29ecde59935afa87b6d11a1d3a108 
fedora/1/updates-testing/SRPMS/postgresql-7.3.9-1.2.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050307/2fc43c1e/attachment.sig>

From marcdeslauriers at videotron.ca  Tue Mar  8 03:20:20 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Mon, 07 Mar 2005 22:20:20 -0500
Subject: Fedora Legacy Test Update Notification: imap
Message-ID: <422D19F4.40806@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2443
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2443
2005-03-07
---------------------------------------------------------------------

Name        : imap
Versions    : rh7.3: imap-2001a-10.1.legacy
Versions    : rh9: imap-2001a-18.1.legacy
Versions    : fc1: imap-2002d-3.1.legacy
Summary     : Server daemons for IMAP and POP network mail protocols.
Description :
The imap package provides server daemons for both the IMAP (Internet
Message Access Protocol) and POP (Post Office Protocol) mail access
protocols. The POP protocol uses a "post office" machine to collect
mail for users and allows users to download their mail to their local
machine for reading. The IMAP protocol allows a user to read mail on a
remote machine without downloading it to their local machine.

---------------------------------------------------------------------
Update Information:

Updated imap packages that fix security issues are now available.

The imap package provides server daemons for both the IMAP (Internet
Message Access Protocol) and POP (Post Office Protocol) mail access
protocols.

A buffer overflow flaw was found in the c-client IMAP client. An attacker
could create a malicious IMAP server that if connected to by a victim could
execute arbitrary code on the client machine. The Common Vulnerabilities
and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0297
to this issue.

A logic error in the CRAM-MD5 code in the University of Washington IMAP
(UW-IMAP) server was discovered. When Challenge-Response Authentication
Mechanism with MD5 (CRAM-MD5) is enabled, UW-IMAP does not properly enforce
all the required conditions for successful authentication, which could
allow remote attackers to authenticate as arbitrary users. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name
CAN-2005-0198 to this issue.

Users of imap are advised to upgrade to these updated packages, which
contain a backported patch to correct this issue.

---------------------------------------------------------------------
Changelogs

rh73:
* Thu Mar 03 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
2001a-10.1.legacy
- Added security patch for CAN-2003-0297

rh9:
* Thu Mar 03 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
2001a-18.1.legacy
- Added security patch for CAN-2003-0297

fc1:
* Thu Mar 03 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
1:2002d-3.1.legacy
- Added patch for CAN-2005-0198

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
3dac230d4b4ed898d1adaf3e58ce5b13e80159dc 
redhat/7.3/updates-testing/i386/imap-2001a-10.1.legacy.i386.rpm
766f42e2292693d1b0500dc151823d13382595c5 
redhat/7.3/updates-testing/i386/imap-devel-2001a-10.1.legacy.i386.rpm
787996b44c48692932c345e72d32b4460576570e 
redhat/7.3/updates-testing/SRPMS/imap-2001a-10.1.legacy.src.rpm

rh9:
f4998e31f0121b54e6b618007a6c1a7ff8a08182 
redhat/9/updates-testing/i386/imap-2001a-18.1.legacy.i386.rpm
d99cd4c0c0c83328a309c0263682dfbaa4e752ed 
redhat/9/updates-testing/i386/imap-devel-2001a-18.1.legacy.i386.rpm
6f8cac716e78dfcfe307dc5b4db6c604e2f47049 
redhat/9/updates-testing/SRPMS/imap-2001a-18.1.legacy.src.rpm

fc1:
69ef237bbd50fc425e00be7093d3de1ddd919de1 
fedora/1/updates-testing/i386/imap-2002d-3.1.legacy.i386.rpm
028d73692c13e4182788605987d246629e24df07 
fedora/1/updates-testing/i386/imap-devel-2002d-3.1.legacy.i386.rpm
732db7ca229fc939456a2db14ae65c46f2fd7586 
fedora/1/updates-testing/SRPMS/imap-2002d-3.1.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050307/d9744c34/attachment.sig>

From marcdeslauriers at videotron.ca  Wed Mar  9 04:29:57 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Tue, 08 Mar 2005 23:29:57 -0500
Subject: Problems with php updates
Message-ID: <1110342598.6625.8.camel@mdlinux>

Hi,

It appears some people are having problems with the latest FL php
updates for rh7.3 and rh9.

If anyone here is having difficulties with them, please take a look at
the following bugzilla issue, add some info, and try out the packages
inside:

https://bugzilla.fedora.us/show_bug.cgi?id=2444

Thanks,

Marc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050308/eb155e15/attachment.sig>

From ismanager at ccbnpts.com  Wed Mar  9 16:38:40 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Wed, 9 Mar 2005 10:38:40 -0600
Subject: Problems with php updates
In-Reply-To: <1110342598.6625.8.camel@mdlinux>
Message-ID: <00d701c524c6$7364d640$7202a8c0@ccb2vpjza>

Just a FYI ...

Using SquirrelMail 1.4.3a + xss patch does not cause a segfault when
used with the php-0-4.1.2-7.3.14.legacy.i386 package. At least not on my
system.

Environment:
Athlon 2600+ XP, 768mb RAM
RedHat 7.3 + all fixes via Fedora Legacy
SquirrelMail 1.4.3a + xss patch
php-4.1.2-7.3.14.legacy

Server Info Dump:
Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_ssl/2.8.12 OpenSSL/0.9.6b
DAV/1.0.3 PHP/4.1.2 mod_perl/1.26

Paul Pettit
CTO and IS Manager
Consistent Computer Bargains Inc.

I've heard it said that the proof of lunacy is when you repeat the same
steps expecting different results.  I say it's proof that you're a
Microsoft user. - comment by deshi777 on experts-exchange.com

> -----Original Message-----
> From: fedora-legacy-list-bounces at redhat.com 
> [mailto:fedora-legacy-list-bounces at redhat.com] On Behalf Of 
> Marc Deslauriers
> Sent: Tuesday, March 08, 2005 10:30 PM
> To: fedora-legacy-list at redhat.com
> Subject: Problems with php updates
> 
> 
> Hi,
> 
> It appears some people are having problems with the latest FL php
> updates for rh7.3 and rh9.
> 
> If anyone here is having difficulties with them, please take a look at
> the following bugzilla issue, add some info, and try out the packages
> inside:
> 
https://bugzilla.fedora.us/show_bug.cgi?id=2444

Thanks,

Marc.




From menscher at uiuc.edu  Wed Mar  9 20:52:10 2005
From: menscher at uiuc.edu (Damian Menscher)
Date: Wed, 9 Mar 2005 14:52:10 -0600 (CST)
Subject: recent rh9 updates broke rpm?
Message-ID: <417FBD79471FC74E98397AF3640E6AC5153DB2@phyexha.physics.uiuc.edu>

Looking to see if anyone else had this problem this week:

Setup: I have eight identical machines running RH9 using yum in a 
nightly cronjob to install the legacy updates.  This has all worked 
perfectly for the past year or so (except for occasional hiccups due to 
bad downloads, etc).  Recently there was a kernel update, and I rebooted 
all 8 machines on Feb 27 at 15:04.  Yum continued to run nightly since 
then, and has installed the cups updates of March 2/3 on all machines 
without incident (some got it Mar 2, some Mar 3 due to network 
flakiness).  Therefore I doubt that the reboot is directly related.

Two nights ago, I got email reports from 4 of the 8 machines indicating 
that yum had segfaulted.  I guessed it was a network glitch, but last 
night I got two more segfaults, and two machines with a hung yum process 
(waiting for a futex() to unlock).

Questions: Why did this affect only half of my machines?  How could the 
RPM databases have been broken?  The update that seems to be killing 
them is less-378-7.2.legacy, which has managed to get installed even on 
two of the broken machines.

Finally, I know the standard thing-to-do is rm -f /var/lib/rpm/__db* and 
install a more recent version of rpm.  But I've already got rpm-4.2-1 on 
these machines, so those locking issues shouldn't be causing a problem. 
Besides, the reboot would have done that rm -f as part of rc.sysinit.

Anyone else have this problem with this week's updates?  It'd be nice to 
know that it's not just me....  Other suggestions also welcome.

Damian Menscher
-- 
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <menscher at uiuc.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-



From shurdeek at routehat.org  Wed Mar  9 21:12:22 2005
From: shurdeek at routehat.org (Peter Surda)
Date: Wed, 9 Mar 2005 22:12:22 +0100
Subject: recent rh9 updates broke rpm?
In-Reply-To: <417FBD79471FC74E98397AF3640E6AC5153DB2@phyexha.physics.uiuc.edu>
References: <417FBD79471FC74E98397AF3640E6AC5153DB2@phyexha.physics.uiuc.edu>
Message-ID: <20050309211221.GM8913@soldats.localdomain>

On Wed, Mar 09, 2005 at 02:52:10PM -0600, Damian Menscher wrote:
> Anyone else have this problem with this week's updates?  It'd be nice to 
> know that it's not just me....  Other suggestions also welcome.
Actually, I have exactly the same problem and similarly to your situation, it
only happens on some (in my case one) computer. When I run yum with -d 10, it
says:

[lots of stuff deleted]
Resolving dependencies
Updating: less, i386
localhdrpath= /var/cache/yum/updates/headers/less-0-378-7.2.legacy.i386.hdr
for less i386
Not an install only pkg, adding to ts
Speicherzugriffsfehler

(speicherzugriffsfehler == "memory access error" == segmentation fault)

> Damian Menscher
Bye,

Peter Surda (Shurdeek) <shurdeek at routehat.org>, ICQ 10236103, +436505122023

-- 
                       There's no place like ~



From beartooth at adelphia.net  Wed Mar  9 22:21:35 2005
From: beartooth at adelphia.net (beartooth)
Date: Wed, 09 Mar 2005 17:21:35 -0500
Subject: VDQ : how to print with FC1 and an HP 1310 series.
Message-ID: <pan.2005.03.09.22.21.35.172440@adelphia.net>

This may turn out to be two problems before I'm done, but this is
definitely the first if such be the case.

I bought a new HP, 1310 series; plugged it into a USB port, and rebooted;
Fedora Core 1 ran kudzu, and told me it had configured the printer. So I
opened pine 4.62 and tried to print a message. It couldn't use lpr, cups,
nor CUPS as the default printer. 

Then I brought up a page in Epiphany and tried again. The only difference
I saw was that at least pine had given me an error message.

Once I can print, there *may* be another problem. We run three printers
and five computers. One is a Lexmark, which I declared to be a
single-purpose machine rather than fight any more with trying to get a
driver for linux; it does work with XPPro, which dual-boots on one machine
with FC1 (two hard drives); I mention it only to get it out of the way,
hoping it'll prove irrelevant.

One is an old HP 1100 series, presently a dedicated printer for my wife's
desktop, one floor down; it'll probably have to stay that, though I'd
rather not.

There are two FC1 machines (counting the dual-boot) and an FC2 on my desk,
and a G3 iBook floating wirelessly about the house. All five connect to
the same wireless router -- and so does an itty-bitty Linksys printserver,
about the size of a pack of cigarettes. 

After I get all the machines I can configured to use the 1310 via
direct USB cable, says Linksys, I can just plug the USB cable from
the 1310 into the printserver, and they should all share. Says Linksys. I
hope that's right. But I am not sanguine.

-- 
Beartooth Implacable, Linux Evangelist & Gadfly
neo-redneck, curmudgeonly codger with FC1&2, YDL4, XPPro
Pine 4.62, Pan 0.14.2; Privoxy 3.0.1; Opera 7.54, Firefox 1.0
Bear in mind that I have little idea what I am talking about.




From marcdeslauriers at videotron.ca  Tue Mar  8 03:21:12 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Mon, 07 Mar 2005 22:21:12 -0500
Subject: [FLSA-2005:2404] Updated less package fixes security issue
Message-ID: <422D1A28.9030904@videotron.ca>

---------------------------------------------------------------------
                Fedora Legacy Update Advisory

Synopsis:          Updated less package fixes security issue
Advisory ID:       FLSA:2404
Issue date:        2005-03-07
Product:           Red Hat Linux
Keywords:          Bugfix
Cross references:  https://bugzilla.fedora.us/show_bug.cgi?id=2404
CVE Names:         CAN-2005-0086
---------------------------------------------------------------------


---------------------------------------------------------------------
1. Topic:

An updated less package that fixes segmentation fault when viewing
binary files is now available.

The less utility is a text file browser that resembles more, but has
extended capabilities.

2. Relevant releases/architectures:

Red Hat Linux 9 - i386

3. Problem description:

Victor Ashik discovered a heap based buffer overflow in less, caused by
a patch added to the less package in Red Hat Linux 9. An attacker could
construct a carefully crafted file that could cause less to crash or
possibly execute arbitrary code when opened. The Common Vulnerabilities
and Exposures project (cve.mitre.org) has assigned the name
CAN-2005-0086 to this issue.

All users of the less package should upgrade to this updated package,
which resolves this issue.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

http://bugzilla.fedora.us - bug #2404 - less segfault

6. RPMs required:

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/less-378-7.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/less-378-7.2.legacy.i386.rpm

7. Verification:

SHA1 sum                                 Package Name
---------------------------------------------------------------------

08f54de18179fdaf849cd26d0497531426fd9cc6 
redhat/9/updates/i386/less-378-7.2.legacy.i386.rpm
58ccb5a8cdb72c2a64cd8b41ba8984f2df906a18 
redhat/9/updates/SRPMS/less-378-7.2.legacy.src.rpm

These packages are GPG signed by Fedora Legacy for security.  Our key is
available from http://www.fedoralegacy.org/about/security.php

You can verify each package with the following command:

     rpm --checksig -v <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the sha1sum with the following command:

     sha1sum <filename>

8. References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0086

9. Contact:

The Fedora Legacy security contact is <secnotice at fedoralegacy.org>. More
project details at http://www.fedoralegacy.org

---------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050307/110c5790/attachment.sig>

From marcdeslauriers at videotron.ca  Thu Mar 10 00:53:43 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Wed, 09 Mar 2005 19:53:43 -0500
Subject: [Updated][FLSA-2005:2344] Updated php packages fix security issues
Message-ID: <422F9A97.5010005@videotron.ca>

---------------------------------------------------------------------
                Fedora Legacy Update Advisory

Synopsis:          Updated php packages fix security issues
Advisory ID:       FLSA:2344
Issue date:        2005-03-09
Product:           Red Hat Linux, Fedora Core
Keywords:          Bugfix
Cross references:  https://bugzilla.fedora.us/show_bug.cgi?id=2344
CVE Names:         CAN-2004-0958 CAN-2004-0959 CAN-2004-1018
                    CAN-2004-1019 CAN-2004-1065 CAN-2004-1392
---------------------------------------------------------------------


---------------------------------------------------------------------
1. Topic:

Updated php packages that fix various security issues are now available.

PHP is an HTML-embedded scripting language commonly used with the Apache
HTTP Web server.

[Updated 9th March 2005]
Red Hat Linux 7.3 and Red Hat Linux 9 packages have been updated to
correct a backporting bug which caused php to segfault.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386

3. Problem description:

An information disclosure bug was discovered in the parsing of "GPC"
variables in PHP (query strings or cookies, and POST form data). If
particular scripts used the values of the GPC variables, portions of the
memory space of an httpd child process could be revealed to the client.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0958 to this issue.

A file access bug was discovered in the parsing of "multipart/form-data"
forms, used by PHP scripts which allow file uploads. In particular
configurations, some scripts could allow a malicious client to upload
files to an arbitrary directory where the "apache" user has write
access. The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CAN-2004-0959 to this issue.

Flaws were found in shmop_write, pack, and unpack PHP functions. These
functions are not normally passed user supplied data, so would require a
malicious PHP script to be exploited. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2004-1018 to
this issue.

Flaws including possible information disclosure, double free, and
negative reference index array underflow were found in the
deserialization code of PHP. PHP applications may use the unserialize
function on untrusted user data, which could allow a remote attacker to
gain access to memory or potentially execute arbitrary code. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-1019 to this issue.

A flaw in the exif extension of PHP was found which lead to a stack
overflow. An attacker could create a carefully crafted image file in
such a way that if parsed by a PHP script using the exif extension it
could cause a crash or potentially execute arbitrary code. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-1065 to this issue.

A flaw in the PHP cURL functions allows remote attackers to bypass the
open_basedir setting and read arbitrary files via a file: URL argument
to the curl_init function. The Common Vulnerabilities and Exposures
project (cve.mitre.org) has assigned the name CAN-2004-1392 to this
issue.

Users of PHP should upgrade to these updated packages, which contain
fixes for these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

http://bugzilla.fedora.us - bug #2344 - multiple php vulns

6. RPMs required:

Red Hat Linux 7.3:

SRPM:
http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/php-4.1.2-7.3.16.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-4.1.2-7.3.16.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-devel-4.1.2-7.3.16.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-imap-4.1.2-7.3.16.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-ldap-4.1.2-7.3.16.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-manual-4.1.2-7.3.16.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-mysql-4.1.2-7.3.16.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-odbc-4.1.2-7.3.16.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-pgsql-4.1.2-7.3.16.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/php-snmp-4.1.2-7.3.16.legacy.i386.rpm

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/php-4.2.2-17.12.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/php-4.2.2-17.12.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-devel-4.2.2-17.12.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-imap-4.2.2-17.12.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-ldap-4.2.2-17.12.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-manual-4.2.2-17.12.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-mysql-4.2.2-17.12.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-odbc-4.2.2-17.12.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-pgsql-4.2.2-17.12.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/php-snmp-4.2.2-17.12.legacy.i386.rpm

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/php-4.3.10-1.1.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/php-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-devel-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-domxml-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-imap-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-ldap-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-mbstring-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-mysql-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-odbc-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-pgsql-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-snmp-4.3.10-1.1.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/php-xmlrpc-4.3.10-1.1.legacy.i386.rpm

7. Verification:

SHA1 sum                                 Package Name
---------------------------------------------------------------------

e3f9daeae549b169a6d23185eff0f621216d370b 
redhat/7.3/updates/i386/php-4.1.2-7.3.16.legacy.i386.rpm
6d317b8e40d4acda5297ad8fbef3ee82efc93f41 
redhat/7.3/updates/i386/php-devel-4.1.2-7.3.16.legacy.i386.rpm
d3425f1742fbfe7719857bce39e60af2fd9feee5 
redhat/7.3/updates/i386/php-imap-4.1.2-7.3.16.legacy.i386.rpm
a0f00b99838546b3c577f4a4a091d3d6b7bc074c 
redhat/7.3/updates/i386/php-ldap-4.1.2-7.3.16.legacy.i386.rpm
ace5ec3f6fdf22072878b1bd179918875c42d5cc 
redhat/7.3/updates/i386/php-manual-4.1.2-7.3.16.legacy.i386.rpm
ca07e0bcf2003e92b44c249913d32a2fbc773e8b 
redhat/7.3/updates/i386/php-mysql-4.1.2-7.3.16.legacy.i386.rpm
8ad8f131b8b2584fb82aad582731b274b6f276cf 
redhat/7.3/updates/i386/php-odbc-4.1.2-7.3.16.legacy.i386.rpm
03bcac1613a434ed09ab0a34d8fe6eeb42e4958a 
redhat/7.3/updates/i386/php-pgsql-4.1.2-7.3.16.legacy.i386.rpm
6dea4a944d94c0bca441db66f451362e8c4aabbc 
redhat/7.3/updates/i386/php-snmp-4.1.2-7.3.16.legacy.i386.rpm
46ea10ec8ac66c1a1d28c36f813882d4527266dc 
redhat/7.3/updates/SRPMS/php-4.1.2-7.3.16.legacy.src.rpm
393821cc215925fbb69dba550977eac20affa158 
redhat/9/updates/i386/php-4.2.2-17.12.legacy.i386.rpm
d03475657cc73ec2a4112e8264b545014df676c7 
redhat/9/updates/i386/php-devel-4.2.2-17.12.legacy.i386.rpm
6092eb7d134cc7e6316a5c6a0339914f774b9776 
redhat/9/updates/i386/php-imap-4.2.2-17.12.legacy.i386.rpm
53c36bd673da9f2adcb9590e36b2513f6cbba685 
redhat/9/updates/i386/php-ldap-4.2.2-17.12.legacy.i386.rpm
091820b8df171e0ee9eaae52865b5894a6925670 
redhat/9/updates/i386/php-manual-4.2.2-17.12.legacy.i386.rpm
fbf71d0fdb918c650059e07d9fbf795223e2191a 
redhat/9/updates/i386/php-mysql-4.2.2-17.12.legacy.i386.rpm
2ce46c85ea45eb47fa4999962eca01458bd73532 
redhat/9/updates/i386/php-odbc-4.2.2-17.12.legacy.i386.rpm
fe3ed8936aee6874bd4fa7e19a3c96aaf39b8e31 
redhat/9/updates/i386/php-pgsql-4.2.2-17.12.legacy.i386.rpm
ab25d015acd917ad0c12d13f262ad3d0d29fa1fa 
redhat/9/updates/i386/php-snmp-4.2.2-17.12.legacy.i386.rpm
8e5c6db8bdc50f5662f4e4e29b38e5c46eb9edc3 
redhat/9/updates/SRPMS/php-4.2.2-17.12.legacy.src.rpm
dd0daa7c3d6b4f491605e698c39cb451edff50ba 
fedora/1/updates/i386/php-4.3.10-1.1.legacy.i386.rpm
c07635eca5d2ce4f1972c5faf3e14f4c00a19f2d 
fedora/1/updates/i386/php-devel-4.3.10-1.1.legacy.i386.rpm
2658aabd4ebe409b0b9532baf0894abfe15c0f38 
fedora/1/updates/i386/php-domxml-4.3.10-1.1.legacy.i386.rpm
b38d0ef81f4ccc1ef914bdeb4077461d4dba2d7b 
fedora/1/updates/i386/php-imap-4.3.10-1.1.legacy.i386.rpm
e8d7d69f35641f915edba0eb9c5915db60e318d5 
fedora/1/updates/i386/php-ldap-4.3.10-1.1.legacy.i386.rpm
f9a609b45b56e028080246ea7df8a53d1e0c33b7 
fedora/1/updates/i386/php-mbstring-4.3.10-1.1.legacy.i386.rpm
f34d4ab35fc29149a8c8f84140940c9470356415 
fedora/1/updates/i386/php-mysql-4.3.10-1.1.legacy.i386.rpm
71c362c35b2368348b56d8cd5f7c03812f7b7aa2 
fedora/1/updates/i386/php-odbc-4.3.10-1.1.legacy.i386.rpm
de668bafb64e2f7cb8e3d1add11e8037159ce90d 
fedora/1/updates/i386/php-pgsql-4.3.10-1.1.legacy.i386.rpm
d2bc37081e2633c0cbd721b24cbbeadffc0196be 
fedora/1/updates/i386/php-snmp-4.3.10-1.1.legacy.i386.rpm
1538dab5f7b07a29191f459441478a4c9cc2c11e 
fedora/1/updates/i386/php-xmlrpc-4.3.10-1.1.legacy.i386.rpm
125b673172ebeb9cf0bdefe5adc0060ae10d3c9d 
fedora/1/updates/SRPMS/php-4.3.10-1.1.legacy.src.rpm

These packages are GPG signed by Fedora Legacy for security.  Our key is
available from http://www.fedoralegacy.org/about/security.php

You can verify each package with the following command:

     rpm --checksig -v <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the sha1sum with the following command:

     sha1sum <filename>

8. References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0958
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0959
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1018
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1019
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1065
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1392

9. Contact:

The Fedora Legacy security contact is <secnotice at fedoralegacy.org>. More
project details at http://www.fedoralegacy.org

---------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050309/f1745b8d/attachment.sig>

From joey at clean.q7.com  Thu Mar 10 02:05:25 2005
From: joey at clean.q7.com (Joe Pruett)
Date: Wed, 9 Mar 2005 18:05:25 -0800 (PST)
Subject: recent rh9 updates broke rpm?
In-Reply-To: <417FBD79471FC74E98397AF3640E6AC5153DB2@phyexha.physics.uiuc.edu>
Message-ID: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>

On Wed, 9 Mar 2005, Damian Menscher wrote:

> Questions: Why did this affect only half of my machines?  How could the 
> RPM databases have been broken?  The update that seems to be killing 
> them is less-378-7.2.legacy, which has managed to get installed even on 
> two of the broken machines.
> 
> Finally, I know the standard thing-to-do is rm -f /var/lib/rpm/__db* and 
> install a more recent version of rpm.  But I've already got rpm-4.2-1 on 
> these machines, so those locking issues shouldn't be causing a problem. 
> Besides, the reboot would have done that rm -f as part of rc.sysinit.
> 
> Anyone else have this problem with this week's updates?  It'd be nice to 
> know that it's not just me....  Other suggestions also welcome.

yep, i saw segfaults and hangs with less on a few of my legacy systems.  
rebuilddb cleaned it all up.

if there are known issues with the rh9 rpm, i think we should put a fixed 
one in legacy-utils.



From richard at yaksha.co.nz  Wed Mar  9 19:39:03 2005
From: richard at yaksha.co.nz (Richard Mitchell)
Date: Wed, 9 Mar 2005 19:39:03 -0000
Subject: Positions Vacant
Message-ID: <200503100210.j2A2AB1Z011861@mx3.redhat.com>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050309/432ba07d/attachment.htm>

From menscher at uiuc.edu  Thu Mar 10 04:46:11 2005
From: menscher at uiuc.edu (Damian Menscher)
Date: Wed, 9 Mar 2005 22:46:11 -0600 (CST)
Subject: recent rh9 updates broke rpm?
In-Reply-To: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
References: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
Message-ID: <417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>

On Wed, 9 Mar 2005, Joe Pruett wrote:
> On Wed, 9 Mar 2005, Damian Menscher wrote:
>
>> Questions: Why did this affect only half of my machines?  How could the
>> RPM databases have been broken?  The update that seems to be killing
>> them is less-378-7.2.legacy, which has managed to get installed even on
>> two of the broken machines.
>>
>> Finally, I know the standard thing-to-do is rm -f /var/lib/rpm/__db* and
>> install a more recent version of rpm.  But I've already got rpm-4.2-1 on
>> these machines, so those locking issues shouldn't be causing a problem.
>> Besides, the reboot would have done that rm -f as part of rc.sysinit.
>>
>> Anyone else have this problem with this week's updates?  It'd be nice to
>> know that it's not just me....  Other suggestions also welcome.
>
> yep, i saw segfaults and hangs with less on a few of my legacy systems.
> rebuilddb cleaned it all up.

Talking to others, it's clear that there's some problem with the recent 
"less" rpm.  Here's an example:

# yum -y update
Gathering header information file(s) from server(s)
Server: Fedora Linux / stable for Red Hat Linux 9 (i386)
Server: Macromedia Flash Player for Red Hat Linux 9
Server: Red Hat Linux 9 (i386)
Server: Red Hat Linux 9 (i386) updates
Finding updated packages
Downloading needed headers
Resolving dependencies
Segmentation fault

Trying again with -d 10 it makes it further:
less 100 % done 1/2
while an strace shows it's hung on:
futex(0x40ec10d0, FUTEX_WAIT, 0, NULL

That was on a machine that had just finished an "rpm --rebuilddb" just 
to make sure there wasn't a pre-existing problem.

Another machine died also... I caught it segfaulting with the -d 10:
[snip]
localhdrpath= /var/cache/yum/redhat-os/headers/macutils-0-2.0b3-24.i386.hdr for macutils i386
localhdrpath= /var/cache/yum/fedora-stable/headers/netdiag-0-2.4-0.fdr.4.rh90.i386.hdr for netdiag i386
localhdrpath= /var/cache/yum/redhat-os/headers/pilot-link095-compat-1-0.9.5-22.i386.hdr for pilot-link095-compat i386
Segmentation fault

Finally, I tried (after again cleaning the rpm database):
# strace yum -d 10 -y update
[really huge snip]
pread(6, "\0\0\0\0\1\0\0\0\373\f\0\0\372\f\0\0\374\f\0\0\1\0\346"..., 4096, 13611008) = 4096
pread(6, "\0\0\0\0\1\0\0\0\374\f\0\0\373\f\0\0\375\f\0\0\1\0\346"..., 4096, 13615104) = 4096
pread(6, "\0\0\0\0\1\0\0\0\375\f\0\0\374\f\0\0\376\f\0\0\1\0\346"..., 4096, 13619200) = 4096
pread(6, "\0\0\0\0\1\0\0\0\376\f\0\0\375\f\0\0\377\f\0\0\1\0\346"..., 4096, 13623296) = 4096
pread(6, "\0\0\0\0\1\0\0\0\377\f\0\0\376\f\0\0\0\r\0\0\1\0\346\17"..., 4096, 13627392) = 4096
pread(6, "\0\0\0\0\1\0\0\0\0\r\0\0\377\f\0\0\1\r\0\0\1\0\346\17\0"..., 4096, 13631488) = 4096
pread(6, "\0\0\0\0\1\0\0\0\1\r\0\0\0\r\0\0\2\r\0\0\1\0\346\17\0\7"..., 4096, 13635584) = 4096
pread(6, "\0\0\0\0\1\0\0\0\2\r\0\0\1\r\0\0\3\r\0\0\1\0\346\17\0\7"..., 4096, 13639680) = 4096
pread(6, "\0\0\0\0\1\0\0\0\3\r\0\0\2\r\0\0\4\r\0\0\1\0\346\17\0\7"..., 4096, 13643776) = 4096
pread(6, "\0\0\0\0\1\0\0\0\4\r\0\0\3\r\0\0\5\r\0\0\1\0\346\17\0\7"..., 4096, 13647872) = 4096
pread(6, "\0\0\0\0\1\0\0\0\5\r\0\0\4\r\0\0\6\r\0\0\1\0\346\17\0\007"..., 4096, 13651968) = 4096
pread(6, "\0\0\0\0\1\0\0\0\6\r\0\0\5\r\0\0\7\r\0\0\1\0\346\17\0\7"..., 4096, 13656064) = 4096
pread(6, "\0\0\0\0\1\0\0\0\7\r\0\0\6\r\0\0\10\r\0\0\1\0\346\17\0"..., 4096, 13660160) = 4096
pread(6, "\0\0\0\0\1\0\0\0\10\r\0\0\7\r\0\0\t\r\0\0\1\0\346\17\0"..., 4096, 13664256) = 4096
pread(6, "\0\0\0\0\1\0\0\0\t\r\0\0\10\r\0\0\n\r\0\0\1\0\346\17\0"..., 4096, 13668352) = 4096
pread(6, "\0\0\0\0\1\0\0\0\n\r\0\0\t\r\0\0\v\r\0\0\1\0\346\17\0\7"..., 4096, 13672448) = 4096
pread(6, "\0\0\0\0\1\0\0\0\v\r\0\0\n\r\0\0\f\r\0\0\1\0\346\17\0\7"..., 4096, 13676544) = 4096
pread(6, "\0\0\0\0\1\0\0\0\f\r\0\0\v\r\0\0\r\r\0\0\1\0\346\17\0\7"..., 4096, 13680640) = 4096
pread(6, "\0\0\0\0\1\0\0\0\r\r\0\0\f\r\0\0\16\r\0\0\1\0\346\17\0"..., 4096, 13684736) = 4096
pread(6, "\0\0\0\0\1\0\0\0\16\r\0\0\r\r\0\0\17\r\0\0\1\0\346\17\0"..., 4096, 13688832) = 4096
pread(6, "\0\0\0\0\1\0\0\0\17\r\0\0\16\r\0\0\20\r\0\0\1\0\346\17"..., 4096, 13692928) = 4096
pread(6, "\0\0\0\0\1\0\0\0\20\r\0\0\17\r\0\0\21\r\0\0\1\0\346\17"..., 4096, 13697024) = 4096
pread(6, "\0\0\0\0\1\0\0\0\21\r\0\0\20\r\0\0\22\r\0\0\1\0\346\17"..., 4096, 13701120) = 4096
pread(6, "\0\0\0\0\1\0\0\0\22\r\0\0\21\r\0\0\23\r\0\0\1\0\346\17"..., 4096, 13705216) = 4096
pread(6, "\0\0\0\0\1\0\0\0\23\r\0\0\22\r\0\0\0\0\0\0\1\0\220\5\0"..., 4096, 13709312) = 4096
mmap2(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x41099000
munmap(0x41099000, 262144)              = 0
rt_sigprocmask(SIG_BLOCK, ~[], [33], 8) = 0
rt_sigprocmask(SIG_SETMASK, [33], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [33], 8) = 0
rt_sigprocmask(SIG_SETMASK, [33], NULL, 8) = 0
getgid32()                              = 0
getuid32()                              = 0
stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/var/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/var/lib/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/var/lib/rpm", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/var/lib/rpm", W_OK)            = 0
access("/var/lib/rpm/__db.001", F_OK)   = 0
access("/var/lib/rpm/Requirename", F_OK) = 0
stat64("/var/lib/rpm/Requirename", {st_mode=S_IFREG|0644, st_size=225280, ...}) = 0
open("/var/lib/rpm/Requirename", O_RDONLY|O_LARGEFILE) = 12
fcntl64(12, F_SETFD, FD_CLOEXEC)        = 0
read(12, "\0\0\0\0\1\0\0\0\0\0\0\0a\25\6\0\10\0\0\0\0\20\0\0\0\10"..., 512) = 512
close(12)                               = 0
open("/var/lib/rpm/Requirename", O_RDONLY|O_LARGEFILE) = 12
fcntl64(12, F_SETFD, FD_CLOEXEC)        = 0
fstat64(12, {st_mode=S_IFREG|0644, st_size=225280, ...}) = 0
pread(12, "\0\0\0\0\1\0\0\0\0\0\0\0a\25\6\0\10\0\0\0\0\20\0\0\0\10"..., 4096, 0) = 4096
pread(12, "\0\0\0\0\1\0\0\0\35\0\0\0\0\0\0\0\0\0\0\0j\0R\4\0\2\373"..., 4096, 118784) = 4096
pread(6, "\0\0\0\0\1\0\0\0\363\1\0\0\0\0\0\0\364\1\0\0\1\0\346\17"..., 4096, 2043904) = 4096
pread(6, "\0\0\0\0\1\0\0\0\364\1\0\0\363\1\0\0\365\1\0\0\1\0\346"..., 4096, 2048000) = 4096
pread(6, "\0\0\0\0\1\0\0\0\365\1\0\0\364\1\0\0\366\1\0\0\1\0\346"..., 4096, 2052096) = 4096
pread(6, "\0\0\0\0\1\0\0\0\367\1\0\0\366\1\0\0\370\1\0\0\1\0\346"..., 4096, 2060288) = 4096
pread(6, "\0\0\0\0\1\0\0\0\370\1\0\0\367\1\0\0\371\1\0\0\1\0\346"..., 4096, 2064384) = 4096
pread(6, "\0\0\0\0\1\0\0\0\371\1\0\0\370\1\0\0\372\1\0\0\1\0\346"..., 4096, 2068480) = 4096
pread(6, "\0\0\0\0\1\0\0\0\372\1\0\0\371\1\0\0\373\1\0\0\1\0\346"..., 4096, 2072576) = 4096
pread(6, "\0\0\0\0\1\0\0\0\373\1\0\0\372\1\0\0\374\1\0\0\1\0\346"..., 4096, 2076672) = 4096
pread(6, "\0\0\0\0\1\0\0\0\374\1\0\0\373\1\0\0\375\1\0\0\1\0\346"..., 4096, 2080768) = 4096
pread(6, "\0\0\0\0\1\0\0\0\375\1\0\0\374\1\0\0\376\1\0\0\1\0\346"..., 4096, 2084864) = 4096
pread(6, "\0\0\0\0\1\0\0\0\376\1\0\0\375\1\0\0\377\1\0\0\1\0\346"..., 4096, 2088960) = 4096
pread(6, "\0\0\0\0\1\0\0\0\377\1\0\0\376\1\0\0\0\2\0\0\1\0\346\17"..., 4096, 2093056) = 4096
pread(6, "\0\0\0\0\1\0\0\0\0\2\0\0\377\1\0\0\1\2\0\0\1\0\346\17\0"..., 4096, 2097152) = 4096
pread(6, "\0\0\0\0\1\0\0\0\1\2\0\0\0\2\0\0\2\2\0\0\1\0\346\17\0\7"..., 4096, 2101248) = 4096
pread(6, "\0\0\0\0\1\0\0\0\2\2\0\0\1\2\0\0\3\2\0\0\1\0\346\17\0\7"..., 4096, 2105344) = 4096
pread(6, "\0\0\0\0\1\0\0\0\3\2\0\0\2\2\0\0\4\2\0\0\1\0\346\17\0\7"..., 4096, 2109440) = 4096
pread(6, "\0\0\0\0\1\0\0\0\4\2\0\0\3\2\0\0\5\2\0\0\1\0\346\17\0\7"..., 4096, 2113536) = 4096
pread(6, "\0\0\0\0\1\0\0\0\5\2\0\0\4\2\0\0\6\2\0\0\1\0\346\17\0\7"..., 4096, 2117632) = 4096
pread(6, "\0\0\0\0\1\0\0\0\6\2\0\0\5\2\0\0\7\2\0\0\1\0\346\17\0\7"..., 4096, 2121728) = 4096
pread(6, "\0\0\0\0\1\0\0\0\7\2\0\0\6\2\0\0\10\2\0\0\1\0\346\17\0"..., 4096, 2125824) = 4096
pread(6, "\0\0\0\0\1\0\0\0\10\2\0\0\7\2\0\0\t\2\0\0\1\0\346\17\0"..., 4096, 2129920) = 4096
pread(6, "\0\0\0\0\1\0\0\0\t\2\0\0\10\2\0\0\n\2\0\0\1\0\346\17\0"..., 4096, 2134016) = 4096
pread(6, "\0\0\0\0\1\0\0\0\n\2\0\0\t\2\0\0\v\2\0\0\1\0\346\17\0\7"..., 4096, 2138112) = 4096
pread(6, "\0\0\0\0\1\0\0\0\v\2\0\0\n\2\0\0\f\2\0\0\1\0\346\17\0\7"..., 4096, 2142208) = 4096
pread(6, "\0\0\0\0\1\0\0\0\f\2\0\0\v\2\0\0\r\2\0\0\1\0\346\17\0\7"..., 4096, 2146304) = 4096
pread(6, "\0\0\0\0\1\0\0\0\r\2\0\0\f\2\0\0\16\2\0\0\1\0\346\17\0"..., 4096, 2150400) = 4096
pread(6, "\0\0\0\0\1\0\0\0\16\2\0\0\r\2\0\0\17\2\0\0\1\0\346\17\0"..., 4096, 2154496) = 4096
pread(6, "\0\0\0\0\1\0\0\0\17\2\0\0\16\2\0\0\20\2\0\0\1\0\346\17"..., 4096, 2158592) = 4096
pread(6, "\0\0\0\0\1\0\0\0\20\2\0\0\17\2\0\0\21\2\0\0\1\0\346\17"..., 4096, 2162688) = 4096
pread(6, "\0\0\0\0\1\0\0\0\21\2\0\0\20\2\0\0\22\2\0\0\1\0\346\17"..., 4096, 2166784) = 4096
pread(6, "\0\0\0\0\1\0\0\0\22\2\0\0\21\2\0\0\23\2\0\0\1\0\346\17"..., 4096, 2170880) = 4096
pread(6, "\0\0\0\0\1\0\0\0\23\2\0\0\22\2\0\0\0\0\0\0\1\0\200\n\0"..., 4096, 2174976) = 4096
mmap2(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x41099000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++


My machines are all running kernel-smp-2.4.20-42.9.legacy with 
yum-2.0.4-2 and rpm-4.2-1.  Has anyone seen this on a NON-smp machine? 
Or with yum-2.0.5?  I'm hoping to narrow down the bug a bit further.

Damian Menscher
-- 
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <menscher at uiuc.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-



From tdiehl at rogueind.com  Thu Mar 10 05:20:20 2005
From: tdiehl at rogueind.com (Tom Diehl)
Date: Thu, 10 Mar 2005 00:20:20 -0500 (EST)
Subject: recent rh9 updates broke rpm?
In-Reply-To: <417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
References: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
Message-ID: <Pine.LNX.4.58.0503100013210.5226@tigger.rogueind.com>

On Wed, 9 Mar 2005, Damian Menscher wrote:

> My machines are all running kernel-smp-2.4.20-42.9.legacy with 
> yum-2.0.4-2 and rpm-4.2-1.  Has anyone seen this on a NON-smp machine? 
> Or with yum-2.0.5?  I'm hoping to narrow down the bug a bit further.

I am seeing a segfault also. I did the rpm --rebuilddb thing and rm'd the
lock files but no change.

This is a UP machine.

FWIW:
(sylvester pts1) # uname -r
2.4.20-42.9.legacy
(sylvester pts1) # rpm -q yum
yum-2.0.8-1.mtd
(sylvester pts1) # rpm -q rpm
rpm-4.2-1
(sylvester pts1) # rpm -q redhat-release
redhat-release-9-3
(sylvester pts1) #

The yum rpm is a custom rpm I build for use with my private repos. Only the
config files are changed to protect the innocent. This has been running fine
since yum-2.0.8 was released up until the less rpm hit the legacy repos.

If you need more info just ask.

Regards,

Tom Diehl		tdiehl at rogueind.com		Spamtrap address mtd123 at rogueind.com



From skvidal at phy.duke.edu  Thu Mar 10 05:55:03 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 10 Mar 2005 00:55:03 -0500
Subject: recent rh9 updates broke rpm?
In-Reply-To: <417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
References: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
Message-ID: <1110434103.31871.101.camel@cutter>


> My machines are all running kernel-smp-2.4.20-42.9.legacy with 
> yum-2.0.4-2 and rpm-4.2-1.  Has anyone seen this on a NON-smp machine? 
> Or with yum-2.0.5?  I'm hoping to narrow down the bug a bit further.

changes b/t 2.0.4 and 2.0.5 were not major - mostly functional bugs
nothing architectural.

-sv




From menscher at uiuc.edu  Thu Mar 10 06:27:47 2005
From: menscher at uiuc.edu (Damian Menscher)
Date: Thu, 10 Mar 2005 00:27:47 -0600 (CST)
Subject: recent rh9 updates broke rpm?
In-Reply-To: <1110434103.31871.101.camel@cutter>
References: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
	<1110434103.31871.101.camel@cutter>
Message-ID: <Pine.LNX.4.61.0503100025000.1382@lx2.physics.uiuc.edu>

On Thu, 10 Mar 2005, seth vidal wrote:

>> My machines are all running kernel-smp-2.4.20-42.9.legacy with
>> yum-2.0.4-2 and rpm-4.2-1.  Has anyone seen this on a NON-smp machine?
>> Or with yum-2.0.5?  I'm hoping to narrow down the bug a bit further.
>
> changes b/t 2.0.4 and 2.0.5 were not major - mostly functional bugs
> nothing architectural.

Just a thought, but does yum or rpm depend on less in any way?  A race 
condition (attempting to run the less binary during the brief moment 
when the package is being replaced) might explain why such a simple 
package could be causing such a troublesome update for several of us.

Damian Menscher
-- 
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <menscher at uiuc.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-



From skvidal at phy.duke.edu  Thu Mar 10 06:33:23 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 10 Mar 2005 01:33:23 -0500
Subject: recent rh9 updates broke rpm?
In-Reply-To: <Pine.LNX.4.61.0503100025000.1382@lx2.physics.uiuc.edu>
References: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
	<1110434103.31871.101.camel@cutter>
	<Pine.LNX.4.61.0503100025000.1382@lx2.physics.uiuc.edu>
Message-ID: <1110436403.31871.111.camel@cutter>

On Thu, 2005-03-10 at 00:27 -0600, Damian Menscher wrote:
> On Thu, 10 Mar 2005, seth vidal wrote:
> 
> >> My machines are all running kernel-smp-2.4.20-42.9.legacy with
> >> yum-2.0.4-2 and rpm-4.2-1.  Has anyone seen this on a NON-smp machine?
> >> Or with yum-2.0.5?  I'm hoping to narrow down the bug a bit further.
> >
> > changes b/t 2.0.4 and 2.0.5 were not major - mostly functional bugs
> > nothing architectural.
> 
> Just a thought, but does yum or rpm depend on less in any way?  A race 
> condition (attempting to run the less binary during the brief moment 
> when the package is being replaced) might explain why such a simple 
> package could be causing such a troublesome update for several of us.

yum doesn't.

I'd be deeply surprised if rpm did.

-sv




From menscher at uiuc.edu  Thu Mar 10 07:30:24 2005
From: menscher at uiuc.edu (Damian Menscher)
Date: Thu, 10 Mar 2005 01:30:24 -0600 (CST)
Subject: recent rh9 updates broke rpm?
In-Reply-To: <417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
References: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
Message-ID: <Pine.LNX.4.61.0503100127310.1382@lx2.physics.uiuc.edu>

On Wed, 9 Mar 2005, Damian Menscher wrote:
>
> Talking to others, it's clear that there's some problem with the recent 
> "less" rpm.  Here's an example:

Here's another example, where the strace'd yum process hung on a 
futex().  Note that this is happening mid-way through the rpm 
installation.  Hopefully it's not screwing over my system too badly....

[snip beginning of yum -d 10 -y update]
select(14, NULL, [13], NULL, {2, 0})    = 1 (out [13], left {2, 0})
gettimeofday({1110439589, 627628}, NULL) = 0
write(13, "g\304j-*\366\330D\347M\305\250\233`\264\10g\264\210k$\236"..., 3236) = 3236
gettimeofday({1110439589, 627821}, NULL) = 0
gettimeofday({1110439589, 627897}, NULL) = 0
close(13)                               = 0
gettimeofday({1110439589, 628007}, NULL) = 0
gettimeofday({1110439589, 628072}, NULL) = 0
gettimeofday({1110439589, 628127}, NULL) = 0
munmap(0x404c5000, 8192)                = 0
rename("/usr/share/man/man1/less.1.gz;422ff6a5", "/usr/share/man/man1/less.1.gz") = 0
getuid32()                              = 0
chown32(0x8517950, 0, 0)                = 0
chmod("/usr/share/man/man1/less.1.gz", 0644) = 0
utime("/usr/share/man/man1/less.1.gz", [2005/03/06-19:21:01, 2005/03/06-19:21:01]) = 0
open("/usr/share/man/man1/lesskey.1.gz;422ff6a5", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 13
fcntl64(13, F_SETFD, FD_CLOEXEC)        = 0
gettimeofday({1110439589, 629315}, NULL) = 0
gettimeofday({1110439589, 629392}, NULL) = 0
read(12, "", 16384)                     = 0
gettimeofday({1110439589, 629530}, NULL) = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x404c5000
select(14, NULL, [13], NULL, {2, 0})    = 1 (out [13], left {2, 0})
gettimeofday({1110439589, 629972}, NULL) = 0
write(13, "\37\213\10\10}\254+B\2\3lesskey.1\0\255\32\333v\333\270"..., 3825) = 3825
gettimeofday({1110439589, 630191}, NULL) = 0
gettimeofday({1110439589, 630259}, NULL) = 0
close(13)                               = 0
gettimeofday({1110439589, 630366}, NULL) = 0
gettimeofday({1110439589, 630425}, NULL) = 0
gettimeofday({1110439589, 630479}, NULL) = 0
munmap(0x404c5000, 8192)                = 0
rename("/usr/share/man/man1/lesskey.1.gz;422ff6a5", "/usr/share/man/man1/lesskey.1.gz") = 0
getuid32()                              = 0
chown32(0x8517950, 0, 0)                = 0
chmod("/usr/share/man/man1/lesskey.1.gz", 0644) = 0
utime("/usr/share/man/man1/lesskey.1.gz", [2005/03/06-19:21:01, 2005/03/06-19:21:01]) = 0
brk(0)                                  = 0x8565000
brk(0)                                  = 0x8565000
brk(0x8545000)                          = 0x8545000
brk(0)                                  = 0x8545000
gettimeofday({1110439589, 631594}, NULL) = 0
close(12)                               = 0
munmap(0x4008c000, 4096)                = 0
gettimeofday({1110439589, 631766}, NULL) = 0
munmap(0x404c3000, 8192)                = 0
gettimeofday({1110439589, 631879}, NULL) = 0
gettimeofday({1110439589, 631933}, NULL) = 0
less 100 % done 1/2  done 1/2\rless 0 % done"..., 210
) = 210
time(NULL)                              = 1110439589
rt_sigprocmask(SIG_BLOCK, ~[], [33], 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[HUP INT QUIT PIPE TERM], NULL, 8) = 0
futex(0x40ec1280, FUTEX_WAIT, 0, NULL


Damian Menscher
-- 
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <menscher at uiuc.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-



From mattdm at mattdm.org  Thu Mar 10 14:24:32 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 10 Mar 2005 09:24:32 -0500
Subject: recent rh9 updates broke rpm?
In-Reply-To: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
References: <417FBD79471FC74E98397AF3640E6AC5153DB2@phyexha.physics.uiuc.edu>
	<Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
Message-ID: <20050310142432.GA23802@jadzia.bu.edu>

On Wed, Mar 09, 2005 at 06:05:25PM -0800, Joe Pruett wrote:
> if there are known issues with the rh9 rpm, i think we should put a fixed 
> one in legacy-utils.

Well, there's this:

<http://bugzilla.fedora.us/show_bug.cgi?id=2333>

<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88164>

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From jkeating at j2solutions.net  Thu Mar 10 15:26:14 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 10 Mar 2005 07:26:14 -0800
Subject: Positions Vacant
In-Reply-To: <200503100210.j2A2AB1Z011861@mx3.redhat.com>
References: <200503100210.j2A2AB1Z011861@mx3.redhat.com>
Message-ID: <1110468375.4902.83.camel@localhost.localdomain>

On Wed, 2005-03-09 at 19:39 +0000, Richard Mitchell wrote:
> Hello,
> 
> I would like to apply for the position of Mirror Co-ordinator.  I
> currently run my own IT business and have done so for the past 15
> years.  I use fedora core 3 as a primary operating system for my
> business as well as for home use.
> 
> Up until recently I have hosted many mirrors for many projects
> including apache, tldp and debian.
> 
> I feel that I would be exceptional in this position as I have
> experience dealing with people and also experience with running and
> assisting to run projects within my own business and within our
> clients businesses.

Hi Richard.  This position isn't yet fully defined, but basically I
would like to redirect the 'mirrors at fedoralegacy.org' email address to
you, so that you could handle working with the mirror admins.  There are
some files that have to be managed as well.  A list of mirrors on the
website CVS, an rsync file with the IP addresses of each mirror for a
private port, and just a text file of the ip addresses and email
addresses of each mirror.

Right now these files require a level of access to the servers that I'm
not comfortable with allowing other people to have.  Would you object to
me handing you current copies of these files for you to edit and hand
back to me periodically so that I can update them on the live server?

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050310/bc646eb0/attachment.sig>

From menscher at uiuc.edu  Thu Mar 10 16:25:25 2005
From: menscher at uiuc.edu (Damian Menscher)
Date: Thu, 10 Mar 2005 10:25:25 -0600 (CST)
Subject: recent rh9 updates broke rpm?
In-Reply-To: <20050310142432.GA23802@jadzia.bu.edu>
References: <417FBD79471FC74E98397AF3640E6AC5153DB2@phyexha.physics.uiuc.edu>
	<Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<20050310142432.GA23802@jadzia.bu.edu>
Message-ID: <417FBD79471FC74E98397AF3640E6AC5153DB4@phyexha.physics.uiuc.edu>

On Thu, 10 Mar 2005, Matthew Miller wrote:
> On Wed, Mar 09, 2005 at 06:05:25PM -0800, Joe Pruett wrote:
>> if there are known issues with the rh9 rpm, i think we should put a fixed
>> one in legacy-utils.
>
> Well, there's this:
> <http://bugzilla.fedora.us/show_bug.cgi?id=2333>
> <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88164>

Ok, so those bug reports suggest running rpm-4.2-1.  I ruled that
cause out in my post that started this thread.  I quote myself:

"""
Finally, I know the standard thing-to-do is rm -f /var/lib/rpm/__db* and 
install a more recent version of rpm.  But I've already got rpm-4.2-1 on 
these machines, so those locking issues shouldn't be causing a problem. 
"""

I guess I should try installing the package directly with rpm, rather 
than with yum, and see if it's successful.  Unless anyone can make sense 
of the two strace outputs I posted....

Damian Menscher
-- 
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <menscher at uiuc.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-



From jimpop at yahoo.com  Thu Mar 10 16:29:17 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Thu, 10 Mar 2005 11:29:17 -0500
Subject: Positions Vacant
In-Reply-To: <1110468375.4902.83.camel@localhost.localdomain>
References: <200503100210.j2A2AB1Z011861@mx3.redhat.com>
	<1110468375.4902.83.camel@localhost.localdomain>
Message-ID: <1110472157.3574.28.camel@blue>

Is there some numbers on the b/w requirements or a mirror?

-Jim P.

On Thu, 2005-03-10 at 07:26 -0800, Jesse Keating wrote:
> On Wed, 2005-03-09 at 19:39 +0000, Richard Mitchell wrote:
> > Hello,
> > 
> > I would like to apply for the position of Mirror Co-ordinator.  I
> > currently run my own IT business and have done so for the past 15
> > years.  I use fedora core 3 as a primary operating system for my
> > business as well as for home use.
> > 
> > Up until recently I have hosted many mirrors for many projects
> > including apache, tldp and debian.
> > 
> > I feel that I would be exceptional in this position as I have
> > experience dealing with people and also experience with running and
> > assisting to run projects within my own business and within our
> > clients businesses.
> 
> Hi Richard.  This position isn't yet fully defined, but basically I
> would like to redirect the 'mirrors at fedoralegacy.org' email address to
> you, so that you could handle working with the mirror admins.  There are
> some files that have to be managed as well.  A list of mirrors on the
> website CVS, an rsync file with the IP addresses of each mirror for a
> private port, and just a text file of the ip addresses and email
> addresses of each mirror.
> 
> Right now these files require a level of access to the servers that I'm
> not comfortable with allowing other people to have.  Would you object to
> me handing you current copies of these files for you to edit and hand
> back to me periodically so that I can update them on the live server?
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list



From jkeating at j2solutions.net  Thu Mar 10 16:47:10 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 10 Mar 2005 08:47:10 -0800
Subject: Positions Vacant
In-Reply-To: <1110472157.3574.28.camel@blue>
References: <200503100210.j2A2AB1Z011861@mx3.redhat.com>
	<1110468375.4902.83.camel@localhost.localdomain>
	<1110472157.3574.28.camel@blue>
Message-ID: <1110473230.5489.183.camel@jkeating2.hq.pogolinux.com>

On Thu, 2005-03-10 at 11:29 -0500, Jim Popovitch wrote:
> Is there some numbers on the b/w requirements or a mirror?

That is really tough to estimate.  It all depends on how many users hit
your mirror.  The best I can say is implement some bandwidth throttling
tool so that regardless of the number of users, you won't exceed your
limits.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From misterbawb at gmail.com  Thu Mar 10 19:42:59 2005
From: misterbawb at gmail.com (misterbawb at gmail.com)
Date: Thu, 10 Mar 2005 14:42:59 -0500
Subject: Positions Vacant
In-Reply-To: <1110472157.3574.28.camel@blue>
References: <200503100210.j2A2AB1Z011861@mx3.redhat.com>
	<1110468375.4902.83.camel@localhost.localdomain>
	<1110472157.3574.28.camel@blue>
Message-ID: <fa7105a5050310114239a188c7@mail.gmail.com>

On Thu, 10 Mar 2005 11:29:17 -0500, Jim Popovitch <jimpop at yahoo.com> wrote:
> Is there some numbers on the b/w requirements or a mirror?

The numbers range from 1gb/day to 9gb/day from fedoralegacy on my
public mirror.  9gb/day = 833 kbit/s avg.  Assuming a 1:3 ratio of
average to peak traffic, that'd give 2.5mbit/s peak traffic.



From marcdeslauriers at videotron.ca  Fri Mar 11 00:39:40 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Thu, 10 Mar 2005 19:39:40 -0500
Subject: recent rh9 updates broke rpm?
In-Reply-To: <417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
References: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
Message-ID: <1110501580.3834.9.camel@mdlinux>

On Wed, 2005-03-09 at 22:46 -0600, Damian Menscher wrote:
> On Wed, 9 Mar 2005, Joe Pruett wrote:
> > On Wed, 9 Mar 2005, Damian Menscher wrote:
> Talking to others, it's clear that there's some problem with the recent 
> "less" rpm.  Here's an example:

OK, I removed less from the updates directory and put it back into
updates-testing.

Please remove your __db* files, clear your yum cache and tell me if
updates are still hanging yum/rpm.

thanks,

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050310/2468ce3e/attachment.sig>

From cra at WPI.EDU  Fri Mar 11 01:18:11 2005
From: cra at WPI.EDU (Chuck R. Anderson)
Date: Thu, 10 Mar 2005 20:18:11 -0500
Subject: recent rh9 updates broke rpm?
In-Reply-To: <1110501580.3834.9.camel@mdlinux>
References: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
	<1110501580.3834.9.camel@mdlinux>
Message-ID: <20050311011811.GF30899@angus.ind.WPI.EDU>

On Thu, Mar 10, 2005 at 07:39:40PM -0500, Marc Deslauriers wrote:
> On Wed, 2005-03-09 at 22:46 -0600, Damian Menscher wrote:
> > On Wed, 9 Mar 2005, Joe Pruett wrote:
> > > On Wed, 9 Mar 2005, Damian Menscher wrote:
> > Talking to others, it's clear that there's some problem with the recent 
> > "less" rpm.  Here's an example:
> 
> OK, I removed less from the updates directory and put it back into
> updates-testing.

I just got the less update today, and had no problems at all...

Using:

yum-2.0.5-0.9.2.legacy
rpm-4.2-1
less-378-7.2.legacy



From tdiehl at rogueind.com  Fri Mar 11 01:21:40 2005
From: tdiehl at rogueind.com (Tom Diehl)
Date: Thu, 10 Mar 2005 20:21:40 -0500 (EST)
Subject: recent rh9 updates broke rpm?
In-Reply-To: <1110501580.3834.9.camel@mdlinux>
References: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
	<1110501580.3834.9.camel@mdlinux>
Message-ID: <Pine.LNX.4.58.0503102018270.19976@tigger.rogueind.com>

On Thu, 10 Mar 2005 19:39:40 -0500, Marc Deslauriers wrote:

> On Wed, 2005-03-09 at 22:46 -0600, Damian Menscher wrote:
> > On Wed, 9 Mar 2005, Joe Pruett wrote:
> > > On Wed, 9 Mar 2005, Damian Menscher wrote:
> > Talking to others, it's clear that there's some problem with the recent
> > "less" rpm.  Here's an example:
> 
> OK, I removed less from the updates directory and put it back into
> updates-testing.
> 
> Please remove your __db* files, clear your yum cache and tell me if
> updates are still hanging yum/rpm.

Seems to have resolved the problem here. I was able to install and rm another
package using yum.

Regards,

Tom Diehl		tdiehl at rogueind.com		Spamtrap address mtd123 at rogueind.com



From cra at WPI.EDU  Fri Mar 11 01:25:18 2005
From: cra at WPI.EDU (Chuck R. Anderson)
Date: Thu, 10 Mar 2005 20:25:18 -0500
Subject: recent rh9 updates broke rpm?
In-Reply-To: <417FBD79471FC74E98397AF3640E6AC5153DB4@phyexha.physics.uiuc.edu>
References: <417FBD79471FC74E98397AF3640E6AC5153DB2@phyexha.physics.uiuc.edu>
	<Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<20050310142432.GA23802@jadzia.bu.edu>
	<417FBD79471FC74E98397AF3640E6AC5153DB4@phyexha.physics.uiuc.edu>
Message-ID: <20050311012518.GG30899@angus.ind.WPI.EDU>

On Thu, Mar 10, 2005 at 10:25:25AM -0600, Damian Menscher wrote:
> I guess I should try installing the package directly with rpm, rather 
> than with yum, and see if it's successful.  Unless anyone can make sense 
> of the two strace outputs I posted....

If you try this, please post the "rpm -vvv -U" output.



From barbara.pennacchi at istc.cnr.it  Fri Mar 11 14:02:22 2005
From: barbara.pennacchi at istc.cnr.it (Barbara Pennacchi)
Date: Fri, 11 Mar 2005 14:02:22 +0000
Subject: About Fedora Legacy's WikiSite
In-Reply-To: <1110547249l.2434l.1l@sibannac> (from
	barbara.pennacchi@istc.cnr.it on Fri Mar 11 14:20:49 2005)
References: <1110547249l.2434l.1l@sibannac>
Message-ID: <1110549742l.2434l.2l@sibannac>

I forgot who's the guy in charge of the abovesaid wikisite's  
configuration, so forgive me for writing to the whole mailing list.

Please take a look at version 17 of SelfIntroduction page. The e-diots are  
getting nastier. And I'm getting tired of this pingpong-like game.
Maybe it's about time to tighten up a bit access to the editing of  
wikisite? :(

-- 
+--------------------------------------------------------------------+
| Barbara Pennacchi               barbara.pennacchi (at) istc.cnr.it |
|                 Consiglio Nazionale delle Ricerche                 |
|         Istituto di Scienze e Tecnologie della Cognizione          |
|                  V.le Marx 15, 00137 Roma, Italia                  |
|                      http://www.istc.cnr.it/                       |
+--------------------------------------------------------------------+








From ssharma at revsharecorp.com  Sat Mar 12 00:22:47 2005
From: ssharma at revsharecorp.com (Ajay Sharma)
Date: Fri, 11 Mar 2005 16:22:47 -0800
Subject: thank you and future of 7.3
Message-ID: <42323657.10303@revsharecorp.com>

Hi,

I just want to say thanks to everyone supporting Redhat 7.3.   For years 
at work we've been running redhat 6.2 because some closed-source binary 
program wouldn't run on 7.0 and above.  Plus the company folded and 
since we still depend on the app there was no hope.  Other admins before 
me tried to get the program working on other distros but it just 
wouldn't fly.

I installed Redhat 7.3, updated everything with yum and fedoralegacy, 
and installed the compat-glibc package and now I'm have a server that 
has all the security patches applied.

So for that, I just want to say THANK YOU!!!!

I know that 7.3 is super old and I was just wondering if anyone can 
predict how much longer there will be support for it?

Thanks again for the fine work,
Ajay



From rostetter at mail.utexas.edu  Sat Mar 12 03:48:29 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Fri, 11 Mar 2005 21:48:29 -0600
Subject: About Fedora Legacy's WikiSite
In-Reply-To: <1110549742l.2434l.2l@sibannac>
References: <1110547249l.2434l.1l@sibannac> <1110549742l.2434l.2l@sibannac>
Message-ID: <1110599309.438622cb9ab50@mail.ph.utexas.edu>

Quoting Barbara Pennacchi <barbara.pennacchi at istc.cnr.it>:

> I forgot who's the guy in charge of the abovesaid wikisite's
> configuration, so forgive me for writing to the whole mailing list.

Jesse, as far as I know.

> Please take a look at version 17 of SelfIntroduction page. The e-diots are
> getting nastier. And I'm getting tired of this pingpong-like game.
> Maybe it's about time to tighten up a bit access to the editing of
> wikisite? :(

I'm not sure we can.  I'd be in favor of it requiring a password in
addition to a username, but that's just because I'm worried that without
that someone can login with my wiki username and make changes in my name
without my knowledge and make me look bad...

In another project I work on, using different wiki software, each wiki
change is e-mailed to the core developers.  That way the core developers
immediately see any changes, and can "immediately" fix any spam attacks,
bogus entries, etc.  Sounds like that would be a lot of e-mail traffic
but it really isn't (wiki pages are not updated as often as one would
think).   Not sure if the is possible with the FL wiki or not,
but if so I'd volunteer to be one of the wiki "police" as I'm sure a few
others would.

> --
> +--------------------------------------------------------------------+
> | Barbara Pennacchi               barbara.pennacchi (at) istc.cnr.it |
> |                 Consiglio Nazionale delle Ricerche                 |
> |         Istituto di Scienze e Tecnologie della Cognizione          |
> |                  V.le Marx 15, 00137 Roma, Italia                  |
> |                      http://www.istc.cnr.it/                       |
> +--------------------------------------------------------------------+
> 
> 
> 
> 
> 
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
> 


-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Sat Mar 12 03:58:38 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Fri, 11 Mar 2005 21:58:38 -0600
Subject: thank you and future of 7.3
In-Reply-To: <42323657.10303@revsharecorp.com>
References: <42323657.10303@revsharecorp.com>
Message-ID: <1110599918.3dea9ae9b0a0d@mail.ph.utexas.edu>

Quoting Ajay Sharma <ssharma at revsharecorp.com>:

> I know that 7.3 is super old and I was just wondering if anyone can
> predict how much longer there will be support for it?

Can't say, other than "as long as there is community interest."
I'd bet that will be a while, as it has the most community interest
of any of the releases Fedora Legacy maintains.

> Thanks again for the fine work,
> Ajay

-- 
Eric Rostetter



From skvidal at phy.duke.edu  Sat Mar 12 04:08:07 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 11 Mar 2005 23:08:07 -0500
Subject: About Fedora Legacy's WikiSite
In-Reply-To: <1110599309.438622cb9ab50@mail.ph.utexas.edu>
References: <1110547249l.2434l.1l@sibannac> <1110549742l.2434l.2l@sibannac>
	<1110599309.438622cb9ab50@mail.ph.utexas.edu>
Message-ID: <1110600487.21547.1.camel@cutter>


> > Please take a look at version 17 of SelfIntroduction page. The e-diots are
> > getting nastier. And I'm getting tired of this pingpong-like game.
> > Maybe it's about time to tighten up a bit access to the editing of
> > wikisite? :(
> 
> I'm not sure we can.  I'd be in favor of it requiring a password in
> addition to a username, but that's just because I'm worried that without
> that someone can login with my wiki username and make changes in my name
> without my knowledge and make me look bad...
> 

the wiki fedoraproject.org uses requires username+password and people
who are allowed to edit webpages are restricted to another access list.

A wiki makes pages easy to edit, it doesn't necessarily mean it should
be writable for everyone.

-sv




From menscher at uiuc.edu  Sun Mar 13 20:59:22 2005
From: menscher at uiuc.edu (Damian Menscher)
Date: Sun, 13 Mar 2005 14:59:22 -0600 (CST)
Subject: recent rh9 updates broke rpm?
In-Reply-To: <20050311012518.GG30899@angus.ind.WPI.EDU>
References: <417FBD79471FC74E98397AF3640E6AC5153DB2@phyexha.physics.uiuc.edu>
	<Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<20050310142432.GA23802@jadzia.bu.edu>
	<417FBD79471FC74E98397AF3640E6AC5153DB4@phyexha.physics.uiuc.edu>
	<20050311012518.GG30899@angus.ind.WPI.EDU>
Message-ID: <Pine.LNX.4.62.0503131455400.4861@lx2.physics.uiuc.edu>

On Thu, 10 Mar 2005, Chuck R. Anderson wrote:

> On Thu, Mar 10, 2005 at 10:25:25AM -0600, Damian Menscher wrote:
>> I guess I should try installing the package directly with rpm, rather
>> than with yum, and see if it's successful.  Unless anyone can make sense
>> of the two strace outputs I posted....
>
> If you try this, please post the "rpm -vvv -U" output.

When I tried the rpm -U -vvv the less package worked.  This was 
on a machine where yum had failed 3 times.  *shrug*  Unfortunately it 
appears the repository maintainers have decided to just drop the issue, 
and I really don't have time to track this down on my own.

Till next time,

Damian Menscher
-- 
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <menscher at uiuc.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-



From marcdeslauriers at videotron.ca  Sun Mar 13 23:42:08 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sun, 13 Mar 2005 18:42:08 -0500
Subject: recent rh9 updates broke rpm?
In-Reply-To: <Pine.LNX.4.62.0503131455400.4861@lx2.physics.uiuc.edu>
References: <417FBD79471FC74E98397AF3640E6AC5153DB2@phyexha.physics.uiuc.edu>
	<Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<20050310142432.GA23802@jadzia.bu.edu>
	<417FBD79471FC74E98397AF3640E6AC5153DB4@phyexha.physics.uiuc.edu>
	<20050311012518.GG30899@angus.ind.WPI.EDU>
	<Pine.LNX.4.62.0503131455400.4861@lx2.physics.uiuc.edu>
Message-ID: <1110757329.17483.1.camel@mdlinux>

On Sun, 2005-03-13 at 14:59 -0600, Damian Menscher wrote:
> on a machine where yum had failed 3 times.  *shrug*  Unfortunately it 
> appears the repository maintainers have decided to just drop the issue, 
> and I really don't have time to track this down on my own.

Who has decided to drop the issue?

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050313/e35b2ca2/attachment.sig>

From marcdeslauriers at videotron.ca  Sun Mar 13 23:43:25 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Sun, 13 Mar 2005 18:43:25 -0500
Subject: recent rh9 updates broke rpm?
In-Reply-To: <1110501580.3834.9.camel@mdlinux>
References: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
	<1110501580.3834.9.camel@mdlinux>
Message-ID: <1110757405.17483.4.camel@mdlinux>

On Thu, 2005-03-10 at 19:39 -0500, Marc Deslauriers wrote:
> OK, I removed less from the updates directory and put it back into
> updates-testing.
> 
> Please remove your __db* files, clear your yum cache and tell me if
> updates are still hanging yum/rpm.

Nobody has said if their machines are still having hung yum processes
since I have removed the less updates.

Anybody?

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050313/2f173c3c/attachment.sig>

From tdiehl at rogueind.com  Mon Mar 14 02:56:24 2005
From: tdiehl at rogueind.com (Tom Diehl)
Date: Sun, 13 Mar 2005 21:56:24 -0500 (EST)
Subject: recent rh9 updates broke rpm?
In-Reply-To: <1110757405.17483.4.camel@mdlinux>
References: <Pine.LNX.4.44.0503091802370.28725-100000@q7.q7.com>
	<417FBD79471FC74E98397AF3640E6AC5153DB3@phyexha.physics.uiuc.edu>
	<1110501580.3834.9.camel@mdlinux> <1110757405.17483.4.camel@mdlinux>
Message-ID: <Pine.LNX.4.58.0503132152490.1613@tigger.rogueind.com>

On Thu, 2005-03-13 at 18:43:25 -0500, Marc Deslauriers wrote:
>
>On Thu, 2005-03-10 at 19:39 -0500, Marc Deslauriers wrote:
>> OK, I removed less from the updates directory and put it back into
>> updates-testing.
>>
>> Please remove your __db* files, clear your yum cache and tell me if
>> updates are still hanging yum/rpm.
>
>Nobody has said if their machines are still having hung yum processes
>since I have removed the less updates.
>
>Anybody?

Just in case you missed my response before, Rm'ing the less update fixed
the problem here.

Regards,

Tom Diehl		tdiehl at rogueind.com		Spamtrap address mtd123 at rogueind.com



From kelson at speed.net  Mon Mar 14 17:35:52 2005
From: kelson at speed.net (Kelson)
Date: Mon, 14 Mar 2005 09:35:52 -0800
Subject: About Fedora Legacy's WikiSite
In-Reply-To: <1110599309.438622cb9ab50@mail.ph.utexas.edu>
References: <1110547249l.2434l.1l@sibannac> <1110549742l.2434l.2l@sibannac>
	<1110599309.438622cb9ab50@mail.ph.utexas.edu>
Message-ID: <4235CB78.900@speed.net>

Eric Rostetter wrote:
> In another project I work on, using different wiki software, each wiki
> change is e-mailed to the core developers.  That way the core developers
> immediately see any changes, and can "immediately" fix any spam attacks,
> bogus entries, etc.  Sounds like that would be a lot of e-mail traffic
> but it really isn't (wiki pages are not updated as often as one would
> think).

You never know.  If spammers start targetting wikis with the same effort 
they put into blogs, you might start seeing a *lot* of mail.  A typical 
blog comment spam run on my site seems to last about an hour and post 
100-200 comments.  I have countermeasures, of course, and on the rare 
occasions something gets through it's generally a one-off or from a 
small run of about 5, but the scale is still staggering -- and if I had 
to get an email about each attempt, I'd be buried under them.

As for the scale, this does have to do with two things: (1) My blog goes 
back about 2 years, so there are a lot of posts for them to target, and 
(2) it's much simpler to automate sending to comment forms, since it's 
usually a single transaction, than to automate a wiki change, since you 
often have to log in, meaning you need to implement an actual session 
and not just fire off a POST with the right field names.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>



From layer at franz.com  Tue Mar 15 00:04:54 2005
From: layer at franz.com (Kevin Layer)
Date: Mon, 14 Mar 2005 16:04:54 -0800
Subject: problem with yum on rh8
Message-ID: <8294.1110845094@gemini>

-bash-2.05b# yum -y update
yum -y update
Traceback (most recent call last):
  File "/usr/bin/yum", line 22, in ?
    import yummain
  File "yummain.py", line 27, in ?
ImportError: /usr/lib/librpmdb-4.1.so: undefined symbol: __bam_new_filerpmdb
-bash-2.05b# 

I'm pretty sure I saw a yum update recently, too.  Absolutely nothing
other than fedoralegacy.org official updates has been done to this
machine.

Here's the status of yum/rpm:

-bash-2.05b# rpm -qa | grep yum
rpm -qa | grep yum
yum-1.0.3-6.0.7.x.legacy
-bash-2.05b# rpm -qa | grep rpm
rpm -qa | grep rpm
rpm-python-4.1.1-1.8x
redhat-rpm-config-8.0-1
rpm-4.1.1-1.8x
librpm404-4.0.4-8x.27
rpm-build-4.1.1-1.8x
rpm404-python-4.0.4-8x.27
rpm-devel-4.1.1-1.8x
-bash-2.05b# 


Ideas?

-- 
Kevin Layer             layer at Franz.COM        http://www.franz.com/
Franz Inc., 555 12th St., Suite 1450, Oakland, CA  94607, USA
Phone: (510) 452-2000   FAX: (510) 452-0182



From ad+lists at uni-x.org  Tue Mar 15 00:26:27 2005
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Tue, 15 Mar 2005 01:26:27 +0100
Subject: problem with yum on rh8
In-Reply-To: <8294.1110845094@gemini>
References: <8294.1110845094@gemini>
Message-ID: <1110846387.5442.280.camel@serendipity.dogma.lan>

Am Di, den 15.03.2005 schrieb Kevin Layer um 1:04:

> -bash-2.05b# yum -y update
> yum -y update
> Traceback (most recent call last):
>   File "/usr/bin/yum", line 22, in ?
>     import yummain
>   File "yummain.py", line 27, in ?
> ImportError: /usr/lib/librpmdb-4.1.so: undefined symbol: __bam_new_filerpmdb
> -bash-2.05b# 

What do you want to update at all with RH8? RH8 is unsupported since a
longer time, even not supported by the Fedora Legacy Project due to lack
of interest.

> I'm pretty sure I saw a yum update recently, too.  Absolutely nothing
> other than fedoralegacy.org official updates has been done to this
> machine.
> 
> Here's the status of yum/rpm:
> 
> -bash-2.05b# rpm -qa | grep yum
> rpm -qa | grep yum
> yum-1.0.3-6.0.7.x.legacy

This seems not to be a yum for RH8.

http://www.fedoralegacy.org/docs/yum-rh8.php

I highly recommend to at least upgrade to RH9, as long as you are the
only one with root permissions on that host.

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.770_FC2smp 
Serendipity 01:21:39 up 2 days, 3:54, load average: 0.09, 0.17, 0.16 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050315/ca1ffb6a/attachment.sig>

From kelson at speed.net  Tue Mar 15 19:25:48 2005
From: kelson at speed.net (Kelson)
Date: Tue, 15 Mar 2005 11:25:48 -0800
Subject: Fedora Core 2 switch - this week or next?
Message-ID: <423736BC.1030808@speed.net>

I just got an email announcing the release of Fedora Core 4 test 1, 
which I thought had been pushed back to March 21.

So is Fedora Legacy now responsible for FC2, or is there still another 
week of Fedora Core handling it?

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>



From sheltren at cs.ucsb.edu  Tue Mar 15 19:39:41 2005
From: sheltren at cs.ucsb.edu (Jeff Sheltren)
Date: Tue, 15 Mar 2005 11:39:41 -0800
Subject: Fedora Core 2 switch - this week or next?
In-Reply-To: <423736BC.1030808@speed.net>
Message-ID: <BE5C79FD.1F081%sheltren@cs.ucsb.edu>

On 3/15/05 11:25 AM, "Kelson" <kelson at speed.net> wrote:

> I just got an email announcing the release of Fedora Core 4 test 1,
> which I thought had been pushed back to March 21.
> 
> So is Fedora Legacy now responsible for FC2, or is there still another
> week of Fedora Core handling it?

I believe that will coincide with the release of FC4 Test 2, which looks
like it will be on April 11.

-Jeff




From sopwith at redhat.com  Wed Mar 16 17:28:00 2005
From: sopwith at redhat.com (Elliot Lee)
Date: Wed, 16 Mar 2005 12:28:00 -0500
Subject: Fedora Project Mailing Lists reminder
Message-ID: <sopwith.2005-03-16.12.28.00.list-reminder@redhat.com>

This is a reminder of the mailing lists for the Fedora Project, and
the purpose of each list. You can view this information at
http://fedora.redhat.com/participate/communicate/

When you're using these mailing lists, please take the time to choose
the one that is most appropriate to your post. If you don't know the
right mailing list to use for a question or discussion, please contact
me. This will help you get the best possible answer for your question,
and keep other list subscribers happy!

Mailing Lists

Mailing lists are email addresses which send email to all users
subscribed to the mailing list. Sending an email to a mailing list
reaches all users interested in discussing a specific topic and users
available to help other users with the topic.

The following mailing lists are available. To subscribe, send email to <listname>-request at redhat.com
(replace <listname> with the desired mailing list name such as
fedora-list) with the word subscribe in the subject.

fedora-announce-list - Announcements of changes and events. To stay
aware of news, subscribe to this list.
fedora-list - For users of releases. If you want help with a problem
installing or using , this is the list for you.
fedora-test-list - For testers of test releases. If you would like to
discuss experiences using TEST releases, this is the list for you.
fedora-devel-list - For developers, developers, developers. If you are
interested in helping create releases, this is the list for you.
fedora-extras-list - For users and developers of Fedora Extras
fedora-docs-list - For participants of the docs project
fedora-desktop-list - For discussions about desktop issues such as user
interfaces, artwork, and usability
fedora-config-list - For discussions about the development of
configuration tools
fedora-tools-list - For discussions about the toolchain (gcc, gdb,
etc...) within Fedora
fedora-devel-java-list - For discussions about Java-related Fedora
development
fedora-patches-list - For submitting patches to Fedora maintainers, and
used in line with BugWeek
fedora-legacy-announce - For announcements about the Fedora Legacy
Project
fedora-legacy-list - For discussions about the Fedora Legacy Project
fedora-selinux-list - For discussions about the Fedora SELinux Project
fedora-marketing-list - For discussions about marketing and expanding
the Fedora user base
fedora-de-list - For discussions about Fedora in the German language
fedora-es-list - For discussions about Fedora in the Spanish language
fedora-ja-list - For discussions about Fedora in the Japanese language
fedora-i18n-list - For discussions about the internationalization of
Fedora Core
fedora-trans-list - For discussions about translating the software and
documentation associated with the Fedora Project
German: fedora-trans-de
French: fedora-trans-fr
Spanish: fedora-trans-es
Italian: fedora-trans-it
Brazilian Portuguese: fedora-trans-pt_br
Japanese: fedora-trans-ja
Korean: fedora-trans-ko
Simplified Chinese: fedora-trans-zh_cn
Traditional Chinese: fedora-trans-zh_tw



From wendell at BISonline.com  Thu Mar 17 14:02:35 2005
From: wendell at BISonline.com (Wendell Dingus)
Date: Thu, 17 Mar 2005 09:02:35 -0500
Subject: megaraid2 module in legacy kernels
In-Reply-To: <20041216170015.7F20173B83@hormel.redhat.com>
References: <20041216170015.7F20173B83@hormel.redhat.com>
Message-ID: <42398DFB.9010306@BISonline.com>

I just put RH9 on a Gateway 2U rackmount server (sorry, not sure of 
model off-hand). The stock install supported all hardware with no 
issues. So I assumed we were good to go and the server was deployed. 
Later I added yum files for Fedora Legacy and updated the box. The 
2.4.20-42 kernel appears not to have drivers for the raid card and it's 
currently stuck on the stock redhat kernel. Was this intentional or 
perhaps an oversight?

mkinitrd /boot/initrd-2.4.20-42.9.legacybigmem.img 2.4.20-42.9.legacybigmem
No module megaraid2 found for kernel 2.4.20-42.9.legacybigmem

Thanks!



From ben at transprintusa.com  Thu Mar 17 17:20:01 2005
From: ben at transprintusa.com (Ben Hanson)
Date: Thu, 17 Mar 2005 12:20:01 -0500
Subject: megaraid2 module in legacy kernels
Message-ID: <4239BC41.8060105@transprintusa.com>

Yes, I have a Dell server, and the first RH9 kernel upgrade I applied I 
learned quickly that I had to recompile the kernel module for the 
megaraid2 driver before booting the updated kernel.  It can be a bit 
scary when your email server fails to reboot....  My understanding of 
the Legacy project is that it attempts to keep up with security issues 
and occasionally performance issues, but introducing new features or 
kernel drivers is not going to happen, nor probably should it.  RHEL3 
(Centos, Whitebox, Tao, Fermi, etc) is an easy upgrade in my experience, 
and it is supposed to have the megaraid2 driver already compiled into 
the kernel.

Ben Hanson
I. T. MGR
Transprint USA Inc.



From jkeating at j2solutions.net  Thu Mar 17 19:32:52 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 17 Mar 2005 11:32:52 -0800
Subject: megaraid2 module in legacy kernels
In-Reply-To: <42398DFB.9010306@BISonline.com>
References: <20041216170015.7F20173B83@hormel.redhat.com>
	<42398DFB.9010306@BISonline.com>
Message-ID: <1111087972.31967.110.camel@jkeating2.hq.pogolinux.com>

On Thu, 2005-03-17 at 09:02 -0500, Wendell Dingus wrote:
> I just put RH9 on a Gateway 2U rackmount server (sorry, not sure of 
> model off-hand). The stock install supported all hardware with no 
> issues. So I assumed we were good to go and the server was deployed. 
> Later I added yum files for Fedora Legacy and updated the box. The 
> 2.4.20-42 kernel appears not to have drivers for the raid card and
> it's 
> currently stuck on the stock redhat kernel. Was this intentional or 
> perhaps an oversight?
> 
> mkinitrd /boot/initrd-2.4.20-42.9.legacybigmem.img
> 2.4.20-42.9.legacybigmem
> No module megaraid2 found for kernel 2.4.20-42.9.legacybigmem

Did you use a driver disk when you installed?  I don't recall
'megaraid2' being included in stock RHL9 kernels.  If they were, and
they aren't in Legacy kernels, then this is an oversight on our part and
the package needs to be re-rolled.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From pekkas at netcore.fi  Fri Mar 18 19:42:46 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Fri, 18 Mar 2005 21:42:46 +0200 (EET)
Subject: just one VERIFY to be fully published
Message-ID: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>

Hi,

I'll remind again that there are a lot of packages that require only 
minor testing to be fully released.  We need the folks to do this 
VERIFY.

Below is the list of those packages for which a VERIFY is only needed 
on one architecture:

Please help!

==========
openmotif - https://bugzilla.fedora.us/show_bug.cgi?id=2143
Needs VERIFY [fc1]

sharutils - https://bugzilla.fedora.us/show_bug.cgi?id=2155
Needs VERIFY [fc1]

mailman - https://bugzilla.fedora.us/show_bug.cgi?id=2419
Needs VERIFY [rh73]

ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007
Needs VERIFY [fc1]

qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002
Needs VERIFY [rh73]

mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2129
Needs VERIFY [fc1]

ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=2407
Needs VERIFY [fc1]

spamassassin - https://bugzilla.fedora.us/show_bug.cgi?id=2268
Needs VERIFY [fc1]

dhcp - https://bugzilla.fedora.us/show_bug.cgi?id=2251
Needs VERIFY [rh73]

imap - https://bugzilla.fedora.us/show_bug.cgi?id=2443
Needs VERIFY [fc1]
===========

btw, I guess nobody cares about FC1 anymore.  Unless someone actually 
adds a verify to some of those packages, I suggest we just either a) 
release the already verified versions and skip FC1, or b) not verify 
FC1 at all, but ship it in any case.

I really hope there are more people out there willing to do QA for the 
upcoming FC2...



From mattdm at mattdm.org  Fri Mar 18 20:27:50 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 18 Mar 2005 15:27:50 -0500
Subject: just one VERIFY to be fully published
In-Reply-To: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
Message-ID: <20050318202750.GA2010@jadzia.bu.edu>

On Fri, Mar 18, 2005 at 09:42:46PM +0200, Pekka Savola wrote:
> I really hope there are more people out there willing to do QA for the 
> upcoming FC2...

We will be, and I don't think it's just us. RHL 9 to FC1 isn't terribly
compelling, so I think a lot of people just stayed with the older release.
But y'can't do that forever.

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From rob.myers at gtri.gatech.edu  Fri Mar 18 20:45:02 2005
From: rob.myers at gtri.gatech.edu (Rob Myers)
Date: Fri, 18 Mar 2005 15:45:02 -0500
Subject: just one VERIFY to be fully published
In-Reply-To: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
Message-ID: <1111178702.13486.72.camel@rXm-581b.stl.gtri.gatech.edu>

On Fri, 2005-03-18 at 21:42 +0200, Pekka Savola wrote:

<snip>
> btw, I guess nobody cares about FC1 anymore.  Unless someone actually 
> adds a verify to some of those packages, I suggest we just either a) 
> release the already verified versions and skip FC1, or b) not verify 
> FC1 at all, but ship it in any case.

i have been spending my time moving from fc1 to rhel4, but i still have
a few fc1 boxes around.  it is no problem for me to check sha1sums, gpg
signatures, or to verify that packages install.  but, for example,
because i don't use imap it would be a PITA to verify that it functioned
correctly and that its bugs were fixed.

i'll see if i can verify some of the easier packages for fc1...

rob.



From cave.dnb at tiscali.fr  Fri Mar 18 21:06:30 2005
From: cave.dnb at tiscali.fr (nigel henry)
Date: Fri, 18 Mar 2005 21:06:30 +0000
Subject: just one VERIFY to be fully published
In-Reply-To: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
Message-ID: <200503182106.30345.cave.dnb@tiscali.fr>

On Friday 18 Mar 2005 7:42 pm, Pekka Savola wrote:
> Hi,
>
> I'll remind again that there are a lot of packages that require only
> minor testing to be fully released.  We need the folks to do this
> VERIFY.
>
> Below is the list of those packages for which a VERIFY is only needed
> on one architecture:
>
> Please help!
>
> ==========
> openmotif - https://bugzilla.fedora.us/show_bug.cgi?id=2143
> Needs VERIFY [fc1]
>
> sharutils - https://bugzilla.fedora.us/show_bug.cgi?id=2155
> Needs VERIFY [fc1]
>
> mailman - https://bugzilla.fedora.us/show_bug.cgi?id=2419
> Needs VERIFY [rh73]
>
> ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007
> Needs VERIFY [fc1]
>
> qt - https://bugzilla.fedora.us/show_bug.cgi?id=2002
> Needs VERIFY [rh73]
>
> mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2129
> Needs VERIFY [fc1]
>
> ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=2407
> Needs VERIFY [fc1]
>
> spamassassin - https://bugzilla.fedora.us/show_bug.cgi?id=2268
> Needs VERIFY [fc1]
>
> dhcp - https://bugzilla.fedora.us/show_bug.cgi?id=2251
> Needs VERIFY [rh73]
>
> imap - https://bugzilla.fedora.us/show_bug.cgi?id=2443
> Needs VERIFY [fc1]
> ===========
>
> btw, I guess nobody cares about FC1 anymore.  Unless someone actually
> adds a verify to some of those packages, I suggest we just either a)
> release the already verified versions and skip FC1, or b) not verify
> FC1 at all, but ship it in any case.
>
> I really hope there are more people out there willing to do QA for the
> upcoming FC2...
>
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list

I only run Ethereal off the need to be verified list. I use FC1 a lot. Just 
tell me what I need to do and I'll check the Ethereal one out. Nigel



From kwan at digitalhermit.com  Fri Mar 18 23:56:26 2005
From: kwan at digitalhermit.com (Kwan Lowe)
Date: Fri, 18 Mar 2005 18:56:26 -0500
Subject: just one VERIFY to be fully published
In-Reply-To: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
Message-ID: <423B6AAA.2020003@digitalhermit.com>

Pekka Savola wrote:
> Hi,
> 
> I'll remind again that there are a lot of packages that require only 
> minor testing to be fully released.  We need the folks to do this VERIFY.
> 
> Below is the list of those packages for which a VERIFY is only needed on 
> one architecture:
> 

I just installed FC2 under a VMWare session. Tell me what you need done 
with these packages and I can do them over the weekend.



From wendell at BISonline.com  Sat Mar 19 03:12:53 2005
From: wendell at BISonline.com (Wendell Dingus)
Date: Fri, 18 Mar 2005 22:12:53 -0500
Subject: fedora-legacy-list Digest, Vol 13, Issue 29
In-Reply-To: <20050318170028.256DE73976@hormel.redhat.com>
References: <20050318170028.256DE73976@hormel.redhat.com>
Message-ID: <423B98B5.9050901@BISonline.com>

Oops, I apologize. Someone else here installed it and did use a driver 
disk. I've since installed the latest legacy kernel, made an initrd 
using megaraid and rebooted successfully. It's up and going using the 
megaraid driver now and appears at least to be fine. If I understand 
correctly though, megaraid2 is based on 2.x driver code and the 1.x 
stuff isn't near as good. Is that accurate? I downloaded the latest 2.x 
version from LSI's FTP site but it fails to compile. There is a src.rpm 
available from Dell as a DKMS(?) module which I hadn't even previously 
heard of. I'm not having a lot of luck figuring out what that is or how 
to work with it, yet... Any suggestions would be appreciated. Thanks!

>Did you use a driver disk when you installed?  I don't recall
>'megaraid2' being included in stock RHL9 kernels.  If they were, and
>they aren't in Legacy kernels, then this is an oversight on our part and
>the package needs to be re-rolled.
>
>  
>



From menscher at uiuc.edu  Sat Mar 19 03:24:29 2005
From: menscher at uiuc.edu (Damian Menscher)
Date: Fri, 18 Mar 2005 21:24:29 -0600 (CST)
Subject: fedora-legacy-list Digest, Vol 13, Issue 29
In-Reply-To: <423B98B5.9050901@BISonline.com>
References: <20050318170028.256DE73976@hormel.redhat.com>
	<423B98B5.9050901@BISonline.com>
Message-ID: <Pine.LNX.4.62.0503182123230.21837@lx2.physics.uiuc.edu>

On Fri, 18 Mar 2005, Wendell Dingus wrote:

> Oops, I apologize. Someone else here installed it and did use a driver disk. 
> I've since installed the latest legacy kernel, made an initrd using megaraid 
> and rebooted successfully. It's up and going using the megaraid driver now 
> and appears at least to be fine. If I understand correctly though, megaraid2 
> is based on 2.x driver code and the 1.x stuff isn't near as good. Is that 
> accurate? I downloaded the latest 2.x version from LSI's FTP site but it 
> fails to compile. There is a src.rpm available from Dell as a DKMS(?) module 
> which I hadn't even previously heard of. I'm not having a lot of luck 
> figuring out what that is or how to work with it, yet... Any suggestions 
> would be appreciated. Thanks!

The recent RHEL3 kernels contain megaraid2, so perhaps you should just 
recompile a RHEL3 kernel.src.rpm?

Damian Menscher
-- 
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <menscher at uiuc.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-
-=#| The above opinions are not necessarily those of my employers. |#=-



From jkeating at j2solutions.net  Sat Mar 19 03:39:13 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 18 Mar 2005 19:39:13 -0800
Subject: fedora-legacy-list Digest, Vol 13, Issue 29
In-Reply-To: <423B98B5.9050901@BISonline.com>
References: <20050318170028.256DE73976@hormel.redhat.com>
	<423B98B5.9050901@BISonline.com>
Message-ID: <1111203553.4902.85.camel@localhost.localdomain>

On Fri, 2005-03-18 at 22:12 -0500, Wendell Dingus wrote:
> Oops, I apologize. Someone else here installed it and did use a
> driver 
> disk. I've since installed the latest legacy kernel, made an initrd 
> using megaraid and rebooted successfully. It's up and going using the 
> megaraid driver now and appears at least to be fine. If I understand 
> correctly though, megaraid2 is based on 2.x driver code and the 1.x 
> stuff isn't near as good. Is that accurate? I downloaded the latest
> 2.x 
> version from LSI's FTP site but it fails to compile. There is a
> src.rpm 
> available from Dell as a DKMS(?) module which I hadn't even
> previously 
> heard of. I'm not having a lot of luck figuring out what that is or
> how 
> to work with it, yet... Any suggestions would be appreciated. Thanks!

Correct.  Megaraid2 is much better performing.  As for compiling, I'll
leave that up to somebody else.  I haven't looked into that module for a
while.

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050318/769dfc89/attachment.sig>

From pekkas at netcore.fi  Mon Mar 21 13:52:46 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Mon, 21 Mar 2005 15:52:46 +0200 (EET)
Subject: just one VERIFY to be fully published
In-Reply-To: <423B6AAA.2020003@digitalhermit.com>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
Message-ID: <Pine.LNX.4.61.0503211551250.16101@netcore.fi>

On Fri, 18 Mar 2005, Kwan Lowe wrote:
>> I'll remind again that there are a lot of packages that require only minor 
>> testing to be fully released.  We need the folks to do this VERIFY.
>> 
>> Below is the list of those packages for which a VERIFY is only needed on 
>> one architecture:
>
> I just installed FC2 under a VMWare session. Tell me what you need done with 
> these packages and I can do them over the weekend.

Actually, we don't need FC2 verifying just yet, just FC1 (plus RHL9 
and RHL73 :).  I was just pointing out that as Fedora Legacy will drop 
FC1 soon and pick up FC2, I was hoping that there would be more people 
w/ FC2 installed which would be willing to help when the time comes..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From kwan at digitalhermit.com  Mon Mar 21 14:05:39 2005
From: kwan at digitalhermit.com (Kwan Lowe)
Date: Mon, 21 Mar 2005 09:05:39 -0500 (EST)
Subject: just one VERIFY to be fully published
In-Reply-To: <Pine.LNX.4.61.0503211551250.16101@netcore.fi>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi><423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
Message-ID: <14747.12.43.115.206.1111413939.squirrel@digitalhermit.com>

>>
>> I just installed FC2 under a VMWare session. Tell me what you need done with
>> these packages and I can do them over the weekend.
>
> Actually, we don't need FC2 verifying just yet, just FC1 (plus RHL9
> and RHL73 :).  I was just pointing out that as Fedora Legacy will drop
> FC1 soon and pick up FC2, I was hoping that there would be more people
> w/ FC2 installed which would be willing to help when the time comes..

OK, installed FC1 and RHL9 under VMWare... IIRC there were some guidelines for
verification. I'll check the site when I get a chance tonight but I recall
that verification consisted of installing then checking for problems, spurious
dependencies, then seeing if the reason for the patch is fixed?

-- 
* The Digital Hermit   http://www.digitalhermit.com
* Unix and Linux Solutions   kwan at digitalhermit.com



From jkeating at j2solutions.net  Mon Mar 21 16:25:48 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 21 Mar 2005 08:25:48 -0800
Subject: RH bugzilla migration
Message-ID: <1111422348.31967.199.camel@jkeating2.hq.pogolinux.com>

We're preparing to migrate to the Red Hat bugzilla system.  Please do
not add any more comments or file any more bugs at fedora.us.  I will
announce when RH bugzilla is ready for service.

All who handle bugs should sign up for RH bugzilla accounts if you don't
already have one.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From dom at earth.li  Mon Mar 21 20:18:33 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Mon, 21 Mar 2005 20:18:33 +0000
Subject: just one VERIFY to be fully published
In-Reply-To: <14747.12.43.115.206.1111413939.squirrel@digitalhermit.com>
References: <Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<14747.12.43.115.206.1111413939.squirrel@digitalhermit.com>
Message-ID: <20050321201833.GF29340@urchin.earth.li>

On Mon, Mar 21, 2005 at 09:05:39AM -0500, Kwan Lowe wrote:

> OK, installed FC1 and RHL9 under VMWare... IIRC there were some guidelines for
> verification. I'll check the site when I get a chance tonight but I recall
> that verification consisted of installing then checking for problems, spurious
> dependencies, then seeing if the reason for the patch is fixed?

That sums it up pretty nicely, for the VERIFY stage.

For reference, the web page you need is
<http://www.fedoralegacy.org/wiki/index.php/QaTesting>

See the sections entitled "Testing packages for release to updates" and
"Publish Criteria for updates (VERIFY)".

Cheers,

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



From marcdeslauriers at videotron.ca  Mon Mar 21 22:44:52 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Mon, 21 Mar 2005 17:44:52 -0500
Subject: just one VERIFY to be fully published
In-Reply-To: <Pine.LNX.4.61.0503211551250.16101@netcore.fi>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
Message-ID: <1111445092.28926.2.camel@mdlinux>

On Mon, 2005-03-21 at 15:52 +0200, Pekka Savola wrote:
> and RHL73 :).  I was just pointing out that as Fedora Legacy will drop 
> FC1 soon and pick up FC2, I was hoping that there would be more people 

Fedora Legacy isn't dropping FC1 soon. As per the "1-2-3 and out" policy
as defined in the FL FAQ, we'll be dropping FC1 support once Red Hat
stops FC4 maintenance and transfers it to FL.

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050321/4c7369d0/attachment.sig>

From pekkas at netcore.fi  Tue Mar 22 06:55:33 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 22 Mar 2005 08:55:33 +0200 (EET)
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <1111445092.28926.2.camel@mdlinux>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<1111445092.28926.2.camel@mdlinux>
Message-ID: <Pine.LNX.4.61.0503220844250.2950@netcore.fi>

On Mon, 21 Mar 2005, Marc Deslauriers wrote:
> On Mon, 2005-03-21 at 15:52 +0200, Pekka Savola wrote:
>> and RHL73 :).  I was just pointing out that as Fedora Legacy will drop
>> FC1 soon and pick up FC2, I was hoping that there would be more people
>
> Fedora Legacy isn't dropping FC1 soon. As per the "1-2-3 and out" policy
> as defined in the FL FAQ, we'll be dropping FC1 support once Red Hat
> stops FC4 maintenance and transfers it to FL.

Hmm.. maybe the FAQ is not clear enough.
======
Q:  	What does the 1-2-3 and out policy mean?

A:

Fedora Core releases will follow the so-called "1-2-3 and out" policy 
in co-operation with Red Hat/Fedora Core. This means that when the Red 
Hat/Fedora Core group no longer supports a Fedora Core release, Fedora 
Legacy will pick it up and maintain it for two additional Fedora Core 
release cycles. Based on the current schedule for Fedora Core 
releases, this should provide each release with approximately 1.5 
years of total update support.

In short, Fedora Legacy will provide updates for any Fedora Core 
releases up to two versions back from the current release.
=======

The first paragraph seems to be saying (in a bit complex fashion) 
what you were saying -- in practice, that when FC drops FC3 
support, FL drops FC1 support.

However, the last paragraph could be read so that when Fedora Core 4 
is released ("the current release"), FL will ensure that both FC3 and 
FC2 are still supported (but not necessarily FC1).

Two questions:
  1) Does this need to be clarified?
  2) If the 1st paragraph is correct, do we have resources to do that 
kind of continued maintenance?  Unfortunately, at the momemnt, I'm 
rather skeptical...

At most, we should provide FC1 support until a month or two after FC4 
is released. That'd probably allow the folks to migrate from FC1 to 
FC4.  One FC release at the time.

Unless, of course, we drop RHL73 and RHL9.  I wouldn't want that at 
least; that's my main (only) interest in Fedora Legacy at the moment.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From mark.scott at csuk-solutions.net  Tue Mar 22 11:44:37 2005
From: mark.scott at csuk-solutions.net (Mark Scott)
Date: Tue, 22 Mar 2005 11:44:37 +0000
Subject: just one VERIFY to be fully published
In-Reply-To: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
Message-ID: <42400525.5070602@csuk-solutions.net>

Pekka Savola wrote:
> Below is the list of those packages for which a VERIFY is only needed on 
> one architecture:
> 
> ==========
> openmotif - https://bugzilla.fedora.us/show_bug.cgi?id=2143
> Needs VERIFY [fc1]
> 
> sharutils - https://bugzilla.fedora.us/show_bug.cgi?id=2155
> Needs VERIFY [fc1]
> 
> ruby - https://bugzilla.fedora.us/show_bug.cgi?id=2007
> Needs VERIFY [fc1]
> 
> mysql - https://bugzilla.fedora.us/show_bug.cgi?id=2129
> Needs VERIFY [fc1]
> 
> ethereal - https://bugzilla.fedora.us/show_bug.cgi?id=2407
> Needs VERIFY [fc1]
> 
> spamassassin - https://bugzilla.fedora.us/show_bug.cgi?id=2268
> Needs VERIFY [fc1]
> 
> imap - https://bugzilla.fedora.us/show_bug.cgi?id=2443
> Needs VERIFY [fc1]
> ===========
> 

I have checked and marked my verify vote in bugzilla for sharutils and 
spamassassin. I don't know how to use openmotif, ruby or ethereal, and am 
not currently in a position to check mysql or imap on an FC1 machine. I will 
hopefully be able to check mysql shortly.

-- 
Mark Scott
CSUK Solutions Technical Team
Tel: +44 (0)845 6444 185
Email: mark.scott at csuk-solutions.net



From marcdeslauriers at videotron.ca  Tue Mar 22 13:09:08 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Tue, 22 Mar 2005 08:09:08 -0500
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <Pine.LNX.4.61.0503220844250.2950@netcore.fi>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<1111445092.28926.2.camel@mdlinux>
	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>
Message-ID: <1111496949.14670.16.camel@mdlinux>

On Tue, 2005-03-22 at 08:55 +0200, Pekka Savola wrote:

> The first paragraph seems to be saying (in a bit complex fashion) 
> what you were saying -- in practice, that when FC drops FC3 
> support, FL drops FC1 support.
> 

Yes, this is what I understand. (And it seems I can't count, as I had
written FC4... :) )

> However, the last paragraph could be read so that when Fedora Core 4 
> is released ("the current release"), FL will ensure that both FC3 and 
> FC2 are still supported (but not necessarily FC1).
> 

Si in other words, Fedora Legacy will never maintain more than one
unsupported Fedora Core version? It seems to me that prolonging the
usefulness of a release by only six months isn't very long and, IMO, a
waste of time.

> Two questions:
>   1) Does this need to be clarified?

Yes, I think a clear example is needed on the web page.

>   2) If the 1st paragraph is correct, do we have resources to do that 
> kind of continued maintenance?  Unfortunately, at the momemnt, I'm 
> rather skeptical...
> 

We don't really have the resources to maintain any release right now.
Most of the work is done by me, you and Dominic. FL needs more
contributors if it wants to survive, that's for sure.

> At most, we should provide FC1 support until a month or two after FC4 
> is released. That'd probably allow the folks to migrate from FC1 to 
> FC4.  One FC release at the time.
> 
> Unless, of course, we drop RHL73 and RHL9.  I wouldn't want that at 
> least; that's my main (only) interest in Fedora Legacy at the moment.
> 

My only personal interest in FL is FC1 support. I would really like to
see some download statistics of the different releases to see which ones
are useful, and which ones aren't.

Marc.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050322/4b15bc64/attachment.sig>

From marcdeslauriers at videotron.ca  Tue Mar 22 13:10:13 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Tue, 22 Mar 2005 08:10:13 -0500
Subject: just one VERIFY to be fully published
In-Reply-To: <42400525.5070602@csuk-solutions.net>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<42400525.5070602@csuk-solutions.net>
Message-ID: <1111497013.14670.17.camel@mdlinux>

On Tue, 2005-03-22 at 11:44 +0000, Mark Scott wrote:
> I have checked and marked my verify vote in bugzilla for sharutils and 
> spamassassin. I don't know how to use openmotif, ruby or ethereal, and am 
> not currently in a position to check mysql or imap on an FC1 machine. I will 
> hopefully be able to check mysql shortly.
> 

Thank you Mark, your help is greatly appreciated.

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050322/e574afb3/attachment.sig>

From mark.scott at csuk-solutions.net  Tue Mar 22 16:59:01 2005
From: mark.scott at csuk-solutions.net (Mark Scott)
Date: Tue, 22 Mar 2005 16:59:01 +0000
Subject: just one VERIFY to be fully published
In-Reply-To: <1111497013.14670.17.camel@mdlinux>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>	<42400525.5070602@csuk-solutions.net>
	<1111497013.14670.17.camel@mdlinux>
Message-ID: <42404ED5.7020005@csuk-solutions.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marc Deslauriers wrote:
| On Tue, 2005-03-22 at 11:44 +0000, Mark Scott wrote:
|
|>I have checked and marked my verify vote in bugzilla for sharutils and
|>spamassassin. I don't know how to use openmotif, ruby or ethereal, and am
|>not currently in a position to check mysql or imap on an FC1 machine. I will
|>hopefully be able to check mysql shortly.
|>
|
| Thank you Mark, your help is greatly appreciated.
|

And I've just verified MySQL for FC1 as well. I'd been a little quiet in the
verification stage until now because of limited disk space on my FC1 test
machine, but I sorted that out yesterday.

- --
Mark Scott
CSUK Solutions Technical Team
Tel: +44 (0)845 6444 185
Email: mark.scott at csuk-solutions.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCQE7Rl2I0fYrP+68RAkkTAKCJiDozsDUAW+lUgmhlmIcXdAXnZgCfTN1z
uXxPngpi1ZhSvJ8Yd33g8ww=
=VvWM
-----END PGP SIGNATURE-----



From pekkas at netcore.fi  Tue Mar 22 18:30:41 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 22 Mar 2005 20:30:41 +0200 (EET)
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <1111496949.14670.16.camel@mdlinux>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<1111445092.28926.2.camel@mdlinux>
	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>
	<1111496949.14670.16.camel@mdlinux>
Message-ID: <Pine.LNX.4.61.0503222017470.18063@netcore.fi>

On Tue, 22 Mar 2005, Marc Deslauriers wrote:
>> However, the last paragraph could be read so that when Fedora Core 4
>> is released ("the current release"), FL will ensure that both FC3 and
>> FC2 are still supported (but not necessarily FC1).
>>
>
> Si in other words, Fedora Legacy will never maintain more than one
> unsupported Fedora Core version? It seems to me that prolonging the
> usefulness of a release by only six months isn't very long and, IMO, a
> waste of time.

Well, it allows to jump through one version with loose time at 
each end (FC1 -> FC3), and if that's extended slightly, even two 
versions (FC1 -> FC4).  The latter seems pretty good already..

>>   2) If the 1st paragraph is correct, do we have resources to do that
>> kind of continued maintenance?  Unfortunately, at the momemnt, I'm
>> rather skeptical...
>
> We don't really have the resources to maintain any release right now.
> Most of the work is done by me, you and Dominic. FL needs more
> contributors if it wants to survive, that's for sure.

Unfortunately, I fear that's correct -- at least with the current 
update policies.  There seems to be no way to get VERIFY testers for 
non-frequently used packages (e.g., squid) on any platform, much less 
ALL the platforms.

Luckily enough, there _are_ maybe half a dozen people who do help 
occasionally, but it's probably not systematic enough.  I think 
creating packages/PUBLISH part would be doable, but the current 
approach for VERIFY does not cut it.

Either people will have to wake up, or we'll have to start pushing out 
stuff with less QA.  Two possibilities that spring to mind:
  - if the packages have two PUBLISH votes, just require one VERIFY for 
any architecture.  The rest will get forward without any VERIFY votes 
unless someone jumps up within (say) a week.
  - if the packages have one PUBLISH vote, the same as above except 
either wait for (say) 2 weeks or wait indefinitely.

Does anyone know how other community-driven projects, like Debian, 
handle the QA for pending security updates?  We shouldn't be requiring 
more of ourselves than they do.

>> At most, we should provide FC1 support until a month or two after FC4
>> is released. That'd probably allow the folks to migrate from FC1 to
>> FC4.  One FC release at the time.
>>
>> Unless, of course, we drop RHL73 and RHL9.  I wouldn't want that at
>> least; that's my main (only) interest in Fedora Legacy at the moment.
>
> My only personal interest in FL is FC1 support. I would really like to
> see some download statistics of the different releases to see which ones
> are useful, and which ones aren't.

I doubt that would be very conclusive, due to the amount of mirroring, 
but maybe better than nothing.

Do you personally have interests for FC2 or later FC releases, or is 
it just FC1?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From sheltren at cs.ucsb.edu  Tue Mar 22 23:10:19 2005
From: sheltren at cs.ucsb.edu (Jeff Sheltren)
Date: Tue, 22 Mar 2005 15:10:19 -0800
Subject: RH bugzilla migration
In-Reply-To: <1111422348.31967.199.camel@jkeating2.hq.pogolinux.com>
Message-ID: <BE65E5DB.2005B%sheltren@cs.ucsb.edu>

On 3/21/05 8:25 AM, "Jesse Keating" <jkeating at j2solutions.net> wrote:

> We're preparing to migrate to the Red Hat bugzilla system.  Please do
> not add any more comments or file any more bugs at fedora.us.  I will
> announce when RH bugzilla is ready for service.
> 
> All who handle bugs should sign up for RH bugzilla accounts if you don't
> already have one.

Hi Jesse, thanks for working on this.  Any estimates about when we can start
using RedHat's bugzilla?

Thanks,
Jeff




From jkeating at j2solutions.net  Tue Mar 22 23:40:47 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 22 Mar 2005 15:40:47 -0800
Subject: RH bugzilla migration
In-Reply-To: <BE65E5DB.2005B%sheltren@cs.ucsb.edu>
References: <BE65E5DB.2005B%sheltren@cs.ucsb.edu>
Message-ID: <1111534847.3471.95.camel@jkeating2.hq.pogolinux.com>

On Tue, 2005-03-22 at 15:10 -0800, Jeff Sheltren wrote:
> Hi Jesse, thanks for working on this.  Any estimates about when we can
> start
> using RedHat's bugzilla?

I was told that the actual migration would start tomorrow, and finish
tomorrow.  I'm going to say tomorrow evening (PST) or Thursday.

Initially all the bugs will be assigned to a dummy user, and we'll
'cherrypick' bugs out of this dummy user into our various accounts.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From kwan at digitalhermit.com  Wed Mar 23 15:45:43 2005
From: kwan at digitalhermit.com (Kwan Lowe)
Date: Wed, 23 Mar 2005 10:45:43 -0500 (EST)
Subject: Read NTFS with kernel 2.4.20-42.9.legacy?
In-Reply-To: <20050323143431.M13513@mm-vanecek.cc>
References: <20050323143431.M13513@mm-vanecek.cc>
Message-ID: <22507.12.43.115.201.1111592743.squirrel@digitalhermit.com>


> I have a dual boot hard disk and would like to read the NTFS partition from my
> Redhat 9 system. I have the current kernel 2.4.20-42.9.legacy installed.
>
> The folks at
>
> http://www.rhil.net/kernelstuff/modules.html
>
> maintain NTFS kernel modules, but the highest they go is for For kernel
> 2.4.20-30.9.
>
> Can anyone tell me what would be needed to done to get the ntfs module for
> kernel 2.4.20-30.9 to work with 2.4.20-42.9.legacy?
>

http://linux-ntfs.sourceforge.net/rpm/redhat9.html

You can also rebuild the module against the latest sources. The URL you gave
did not have sources (or I didn't see them in a quick scan) so if you need
those specifically it'll be a problem.


-- 
* The Digital Hermit   http://www.digitalhermit.com
* Unix and Linux Solutions   kwan at digitalhermit.com



From eduardo at log.furg.br  Wed Mar 23 16:12:47 2005
From: eduardo at log.furg.br (Eduardo Albergone)
Date: Wed, 23 Mar 2005 13:12:47 -0300
Subject: kernel 2.6
Message-ID: <001601c52fc3$27c865a0$5a4e84c8@anp4>

i need a kertnel 2.6.xx for rh9  where I can find 


eduardo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050323/e855a100/attachment.htm>

From jeroen at easyhosting.nl  Wed Mar 23 16:13:27 2005
From: jeroen at easyhosting.nl (Jeroen Wunnink)
Date: Wed, 23 Mar 2005 17:13:27 +0100
Subject: kernel 2.6
In-Reply-To: <001601c52fc3$27c865a0$5a4e84c8@anp4>
References: <001601c52fc3$27c865a0$5a4e84c8@anp4>
Message-ID: <6.1.2.0.2.20050323171235.03b2f120@mail.easyhosting.nl>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050323/2cf50d8b/attachment.htm>

From bdm at fenrir.org.uk  Wed Mar 23 16:16:43 2005
From: bdm at fenrir.org.uk (Brian Morrison)
Date: Wed, 23 Mar 2005 16:16:43 +0000
Subject: kernel 2.6
In-Reply-To: <001601c52fc3$27c865a0$5a4e84c8@anp4>
References: <001601c52fc3$27c865a0$5a4e84c8@anp4>
Message-ID: <20050323161643.1473626f@ickx.fenrir.org.uk>

On Wed, 23 Mar 2005 13:12:47 -0300 in
001601c52fc3$27c865a0$5a4e84c8 at anp4 "Eduardo Albergone"
<eduardo at log.furg.br> wrote:

> i need a kertnel 2.6.xx for rh9  where I can find 

Build it yourself?

You will need to update a considerable number of other things to use 2.6
kernels with RH9, suggest you read the documentation to find out what.

-- 

Brian Morrison

bdm at fenrir dot org dot uk

GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html



From kwan at digitalhermit.com  Wed Mar 23 16:31:06 2005
From: kwan at digitalhermit.com (Kwan Lowe)
Date: Wed, 23 Mar 2005 11:31:06 -0500 (EST)
Subject: kernel 2.6
In-Reply-To: <20050323161643.1473626f@ickx.fenrir.org.uk>
References: <001601c52fc3$27c865a0$5a4e84c8@anp4>
	<20050323161643.1473626f@ickx.fenrir.org.uk>
Message-ID: <58222.12.43.115.202.1111595466.squirrel@digitalhermit.com>


> On Wed, 23 Mar 2005 13:12:47 -0300 in
> 001601c52fc3$27c865a0$5a4e84c8 at anp4 "Eduardo Albergone"
> <eduardo at log.furg.br> wrote:
>
>> i need a kertnel 2.6.xx for rh9  where I can find
>
> Build it yourself?
>
> You will need to update a considerable number of other things to use 2.6
> kernels with RH9, suggest you read the documentation to find out what.
>

It's doable and there is a noticeable change in how the system feels, but
you're right in that there are a considerable number of (little) things. E.g.,
modification of some rc scripts, newer modutils, misc other changes.


-- 
* The Digital Hermit   http://www.digitalhermit.com
* Unix and Linux Solutions   kwan at digitalhermit.com



From brian.t.brunner at gai-tronics.com  Wed Mar 23 17:04:53 2005
From: brian.t.brunner at gai-tronics.com (Brian T. Brunner)
Date: Wed, 23 Mar 2005 09:04:53 -0800
Subject: kernel 2.6
Message-ID: <s241313e.017@CRPSPKWANW02-IA.hubbell.com>


I'd recommend upgrading to FC3 rather than just upgrading the kernel.
Do you have a reason to stay with RH9?

Brian Brunner
brian.t.brunner at gai-tronics.com
(610)796-5838

>>> kwan at digitalhermit.com 03/23/05 11:31AM >>>

> On Wed, 23 Mar 2005 13:12:47 -0300 in
> 001601c52fc3$27c865a0$5a4e84c8 at anp4 "Eduardo Albergone"
> <eduardo at log.furg.br> wrote:
>
>> i need a kertnel 2.6.xx for rh9  where I can find
>
> Build it yourself?
>
> You will need to update a considerable number of other things to use 2.6
> kernels with RH9, suggest you read the documentation to find out what.
>

It's doable and there is a noticeable change in how the system feels, but
you're right in that there are a considerable number of (little) things. E.g.,
modification of some rc scripts, newer modutils, misc other changes.


-- 
* The Digital Hermit   http://www.digitalhermit.com 
* Unix and Linux Solutions   kwan at digitalhermit.com 

--
fedora-legacy-list mailing list
fedora-legacy-list at redhat.com 
http://www.redhat.com/mailman/listinfo/fedora-legacy-list

*******************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept
for the presence of computer viruses.

www.hubbell.com - Hubbell Incorporated



From rostetter at mail.utexas.edu  Thu Mar 24 20:48:00 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Thu, 24 Mar 2005 14:48:00 -0600
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <Pine.LNX.4.61.0503222017470.18063@netcore.fi>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<1111445092.28926.2.camel@mdlinux>
	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>
	<1111496949.14670.16.camel@mdlinux>
	<Pine.LNX.4.61.0503222017470.18063@netcore.fi>
Message-ID: <1111697280.e39f6c3731083@mail.ph.utexas.edu>


> > Si in other words, Fedora Legacy will never maintain more than one
> > unsupported Fedora Core version? It seems to me that prolonging the
> > usefulness of a release by only six months isn't very long and, IMO, a
> > waste of time.
> 
> Well, it allows to jump through one version with loose time at
> each end (FC1 -> FC3), and if that's extended slightly, even two
> versions (FC1 -> FC4).  The latter seems pretty good already..

The problem with Fedora Core is that it is updated every 6 months or so,
and not at a standard set time.  This means you never know when a new
release will be out, or when support for your current release will be
up; but in either case, you would need to upgrade *right then* to be safe.

Now, in a university environment with a "production" server or machine
which runs an experiment, and so on, you can't just upgrade "right now"
as their are artificial constraints on downtime.  Generally you upgrade
between semesters, during spring break, or during the summer.  Since the
Fedora Core release cycle will rarely hit on one of these time periods,
this is a problem.

By extending its life even 6 months, you can be sure you will get support
until one of your upgrade windows comes along.  At least in my university
environment, I'll have an upgrade cycle about every 6 months.  So I can
now schedule my FC upgrades to match my upgrade schedules.

So, extending the life 6 months is a big deal to people at my university.
Maybe not useful to you, but it is to many.

-- 
Eric Rostetter



From jkeating at j2solutions.net  Thu Mar 24 21:33:59 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 24 Mar 2005 13:33:59 -0800
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <1111496949.14670.16.camel@mdlinux>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<1111445092.28926.2.camel@mdlinux>
	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>
	<1111496949.14670.16.camel@mdlinux>
Message-ID: <1111700039.3471.215.camel@jkeating2.hq.pogolinux.com>

On Tue, 2005-03-22 at 08:09 -0500, Marc Deslauriers wrote:
> Si in other words, Fedora Legacy will never maintain more than one
> unsupported Fedora Core version? It seems to me that prolonging the
> usefulness of a release by only six months isn't very long and, IMO, a
> waste of time.

This is wrong.

Fedora Legacy will support TWO outdated Fedora releases at any time.

When FC4test2 releases, Red Hat will discontinue support for FC2 and
Fedora Legacy will pick it up.  Nothing will happen to Fedora Core 1.
Fedora is supporting FC4 and FC3, Legacy is supporting FC2 and FC1.
Now, when FC5 Test2 releases, Red Hat will drop support for FC3.  Fedora
Legacy picks up FC3 and drops FC1 from it's ranks.

My initial estimate of 1.5 years was a bit low, as I was expecting
faster FC releases than once every 6 months.  So I err'd on the side of
short as it's always a better surprise when you get longer support than
quoted (:

With a 6-month release cycle, RH will support a given FC release for
almost a year.  Then FC will pick it up and support it for almost
another year.  Thats almost 2 years of support.  Perhaps we need to
change the FAQ to say 'between 1.5 and 2 years'.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From marcdeslauriers at videotron.ca  Thu Mar 24 23:09:33 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Thu, 24 Mar 2005 18:09:33 -0500
Subject: Fedora Legacy Test Update Notification: ethereal
Message-ID: <424348AD.9020101@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2453
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2453
2005-03-24
---------------------------------------------------------------------

Name        : ethereal
Versions    : rh7.3: ethereal-0.10.10-0.73.1.legacy
Versions    : rh9: ethereal-0.10.10-0.90.1.legacy
Versions    : fc1: ethereal-0.10.10-1.FC1.1.legacy
Summary     : Network traffic analyzer.
Description :
Ethereal is a network traffic analyzer for Unix-ish operating systems.

---------------------------------------------------------------------
Update Information:

Updated Ethereal packages that fix various security vulnerabilities are
now available.

Ethereal is a program for monitoring network traffic.

A number of security flaws have been discovered in Ethereal. On a system
where Ethereal is running, a remote attacker could send malicious
packets to trigger these flaws and cause Ethereal to crash or
potentially execute arbitrary code.

A flaw in the DICOM dissector could cause a crash. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-1139 to this issue.

A invalid RTP timestamp could hang Ethereal and create a large temporary
file, possibly filling available disk space. (CAN-2004-1140)

The HTTP dissector could access previously-freed memory, causing a
crash. (CAN-2004-1141)

An improperly formatted SMB packet could make Ethereal hang, maximizing
CPU utilization. (CAN-2004-1142)

The COPS dissector could go into an infinite loop. (CAN-2005-0006)

The DLSw dissector could cause an assertion, making Ethereal exit
prematurely. (CAN-2005-0007)

The DNP dissector could cause memory corruption. (CAN-2005-0008)

The Gnutella dissector could cause an assertion, making Ethereal exit
prematurely. (CAN-2005-0009)

The MMSE dissector could free static memory, causing a crash.
(CAN-2005-0010)

The X11 protocol dissector is vulnerable to a string buffer overflow.
(CAN-2005-0084)

A buffer overflow flaw was discovered in the Etheric dissector.
(CAN-2005-0704)

The GPRS-LLC dissector could crash if the "ignore cipher bit" option was
set. (CAN-2005-0705)

A buffer overflow flaw was discovered in the 3GPP2 A11 dissector.
(CAN-2005-0699)

A buffer overflow flaw was discovered in the IAPP dissector.
(CAN-2005-0739)

Users of Ethereal should upgrade to these updated packages which contain
version 0.10.10 and are not vulnerable to these issues.

---------------------------------------------------------------------
Changelogs

rh73:
* Mon Mar 14 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
0.10.10-0.73.1.legacy
- Updated to 0.10.10 to fix multiple security issues (FL#2453)

* Wed Feb 23 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
0.10.9-0.73.2.legacy
- Added the evil plugins hack to get plugins built

* Mon Feb 07 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
0.10.9-0.73.1.legacy
- Updated to 0.10.9 to fix multiple security issues (FL#2407)
- Modified configure parameters
- Added gcc patch

rh9:
* Mon Mar 14 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
0.10.10-0.90.1.legacy
- Updated to 0.10.10 to fix multiple security issues (FL#2453)

* Wed Feb 23 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
0.10.9-0.90.2.legacy
- Added the evil plugins hack to get plugins built

* Tue Feb 08 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
0.10.9-0.90.1.legacy
- Updated to 0.10.9 to fix multiple security issues (FL#2407)
- Modified configure parameters

fc1:
* Mon Mar 14 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
0.10.10-1.FC1.1.legacy
- Updated to 0.10.10 to fix multiple security issues (FL#2453)

* Wed Feb 23 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
0.10.9-1.FC1.2.legacy
- Added the evil plugins hack to get plugins built

* Tue Feb 08 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
0.10.9-1.FC1.1.legacy
- Updated to 0.10.9 to fix multiple security issues (FL#2407)
- Added htmlview patch
- Changed BuildRequires to gtk2

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
a17bbe32f066b6962f507321ea02a966fe152d4d 
redhat/7.3/updates-testing/i386/ethereal-0.10.10-0.73.1.legacy.i386.rpm
70128930bb30e61b043258dd3939cbeeebd25ee6 
redhat/7.3/updates-testing/i386/ethereal-gnome-0.10.10-0.73.1.legacy.i386.rpm
46f6193741ab1ad2a0c14da0e72459c2629ee2d0 
redhat/7.3/updates-testing/SRPMS/ethereal-0.10.10-0.73.1.legacy.src.rpm

rh9:
3a8adb662fcf8513dd558c637271a62502558db7 
redhat/9/updates-testing/i386/ethereal-0.10.10-0.90.1.legacy.i386.rpm
c99bc9df7a9e872bb423791b762d43050091238a 
redhat/9/updates-testing/i386/ethereal-gnome-0.10.10-0.90.1.legacy.i386.rpm
4021715cae9e9a51ef3df402572c60b81ce10702 
redhat/9/updates-testing/SRPMS/ethereal-0.10.10-0.90.1.legacy.src.rpm

fc1:
bfa066398f37ed6b363218b79bcd6b23d3ddb7a1 
fedora/1/updates-testing/i386/ethereal-0.10.10-1.FC1.1.legacy.i386.rpm
10a18378d280efe1b640a5732bd96621047989f2 
fedora/1/updates-testing/i386/ethereal-gnome-0.10.10-1.FC1.1.legacy.i386.rpm
4f7aeac0d63296ebb49a0e83d36a5d985c8c21f9 
fedora/1/updates-testing/SRPMS/ethereal-0.10.10-1.FC1.1.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050324/c6550f7d/attachment.sig>

From marcdeslauriers at videotron.ca  Thu Mar 24 23:06:54 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Thu, 24 Mar 2005 18:06:54 -0500
Subject: [FLSA-2005:2155] Updated sharutils package fixes security issues
Message-ID: <4243480E.3020602@videotron.ca>

---------------------------------------------------------------------
                Fedora Legacy Update Advisory

Synopsis:          Updated sharutils package fixes security issues
Advisory ID:       FLSA:2155
Issue date:        2005-03-24
Product:           Red Hat Linux, Fedora Core
Keywords:          Bugfix
Cross references:  https://bugzilla.fedora.us/show_bug.cgi?id=2155
CVE Names:         N/A
---------------------------------------------------------------------


---------------------------------------------------------------------
1. Topic:

Updated sharutils packages that fix several security issues are now
available.

The sharutils package contains a set of tools for encoding and decoding
packages of files in binary or text format.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386

3. Problem description:

Ulf Harnhammar discovered a buffer overflow in shar.c, where the length
of data returned by the wc command is not checked. Florian Schilhabel
discovered another buffer overflow in unshar.c. Shaun Colley discovered
a stack-based buffer overflow vulnerability in the -o command-line
option handler. An attacker could exploit these vulnerabilities to
execute arbitrary code as the user running one of the sharutils
programs.

All users of sharutils should upgrade to these packages, which resolve
these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

http://bugzilla.fedora.us - bug #2155 - GNU Sharutils Multiple Buffer 
Overflows

6. RPMs required:

Red Hat Linux 7.3:

SRPM:
http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/sharutils-4.2.1-12.7.x.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/7.3/updates/i386/sharutils-4.2.1-12.7.x.legacy.i386.rpm

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/sharutils-4.2.1-16.9.1.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/sharutils-4.2.1-16.9.1.legacy.i386.rpm

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/sharutils-4.2.1-17.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/sharutils-4.2.1-17.2.legacy.i386.rpm

7. Verification:

SHA1 sum                                 Package Name
---------------------------------------------------------------------

192306ce2a6cecb89a950040b850f86a28b26998 
redhat/7.3/updates/i386/sharutils-4.2.1-12.7.x.legacy.i386.rpm
25fdf9cb3237bb9a7f9cd5fd211412d74f4f05c6 
redhat/7.3/updates/SRPMS/sharutils-4.2.1-12.7.x.legacy.src.rpm
d6f2e705ae07f48f5dbbc742f44cbc4dea4c446d 
redhat/9/updates/i386/sharutils-4.2.1-16.9.1.legacy.i386.rpm
678acff4ea03db0aa8bc8f8d90630ffe51d27625 
redhat/9/updates/SRPMS/sharutils-4.2.1-16.9.1.legacy.src.rpm
457f8c7a9bc795c5d33bd8bb3e508e2b1e884df0 
fedora/1/updates/i386/sharutils-4.2.1-17.2.legacy.i386.rpm
7fad3189ab60428f22869daf15304aa1c24b3037 
fedora/1/updates/SRPMS/sharutils-4.2.1-17.2.legacy.src.rpm

These packages are GPG signed by Fedora Legacy for security.  Our key is
available from http://www.fedoralegacy.org/about/security.php

You can verify each package with the following command:

     rpm --checksig -v <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the sha1sum with the following command:

     sha1sum <filename>

8. References:

http://www.securityfocus.com/advisories/7268

9. Contact:

The Fedora Legacy security contact is <secnotice at fedoralegacy.org>. More
project details at http://www.fedoralegacy.org

---------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050324/ed2626e3/attachment.sig>

From marcdeslauriers at videotron.ca  Thu Mar 24 23:07:45 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Thu, 24 Mar 2005 18:07:45 -0500
Subject: [FLSA-2005:2129] Updated mysql packages fix security issues
Message-ID: <42434841.6070707@videotron.ca>

---------------------------------------------------------------------
                Fedora Legacy Update Advisory

Synopsis:          Updated mysql packages fix security issues
Advisory ID:       FLSA:2129
Issue date:        2005-03-24
Product:           Red Hat Linux, Fedora Core
Keywords:          Bugfix
Cross references:  https://bugzilla.fedora.us/show_bug.cgi?id=2129
CVE Names:         CAN-2004-0381 CAN-2004-0388 CAN-2004-0457
                    CAN-2004-0835 CAN-2004-0836 CAN-2004-0837
                    CAN-2004-0957 CAN-2005-0004
---------------------------------------------------------------------


---------------------------------------------------------------------
1. Topic:

Updated mysql packages that fix various security issues are now
available.

MySQL is a multi-user, multi-threaded SQL database server.

2. Relevant releases/architectures:

Red Hat Linux 7.3 - i386
Red Hat Linux 9 - i386
Fedora Core 1 - i386

3. Problem description:

This update fixes a number of potential security problems associated
with careless handling of temporary files. The Common Vulnerabilities
and Exposures project (cve.mitre.org) has assigned the names
CAN-2004-0381, CAN-2004-0388, CAN-2004-0457, and CAN-2005-0004 to these
issues.

Oleksandr Byelkin discovered that "ALTER TABLE ... RENAME" checked
the CREATE/INSERT rights of the old table instead of the new one. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0835 to this issue.

Lukasz Wojtow discovered a buffer overrun in the mysql_real_connect
function. In order to exploit this issue an attacker would need to force
the use of a malicious DNS server (CAN-2004-0836).

Dean Ellis discovered that multiple threads ALTERing the same (or
different) MERGE tables to change the UNION could cause the server to
crash or stall (CAN-2004-0837).

Sergei Golubchik discovered that if a user is granted privileges to a
database with a name containing an underscore ("_"), the user also gains
the ability to grant privileges to other databases with similar names
(CAN-2004-0957).

All users of mysql should upgrade to these updated packages, which
resolve these issues.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

http://bugzilla.fedora.us - bug #2129 - MySQL Remote Buffer Overflow

6. RPMs required:

Red Hat Linux 7.3:

SRPM:
http://download.fedoralegacy.org/redhat/7.3/updates/SRPMS/mysql-3.23.58-1.73.5.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/7.3/updates/i386/mysql-3.23.58-1.73.5.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/mysql-devel-3.23.58-1.73.5.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/7.3/updates/i386/mysql-server-3.23.58-1.73.5.legacy.i386.rpm

Red Hat Linux 9:

SRPM:
http://download.fedoralegacy.org/redhat/9/updates/SRPMS/mysql-3.23.58-1.90.5.legacy.src.rpm

i386:
http://download.fedoralegacy.org/redhat/9/updates/i386/mysql-3.23.58-1.90.5.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/mysql-devel-3.23.58-1.90.5.legacy.i386.rpm
http://download.fedoralegacy.org/redhat/9/updates/i386/mysql-server-3.23.58-1.90.5.legacy.i386.rpm

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/mysql-3.23.58-4.3.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/mysql-3.23.58-4.3.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/mysql-bench-3.23.58-4.3.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/mysql-devel-3.23.58-4.3.legacy.i386.rpm
http://download.fedoralegacy.org/fedora/1/updates/i386/mysql-server-3.23.58-4.3.legacy.i386.rpm

7. Verification:

SHA1 sum                                 Package Name
---------------------------------------------------------------------

04ef0f04b389f7f9fc5bb46f35f81e8503a463ba 
redhat/7.3/updates/i386/mysql-3.23.58-1.73.5.legacy.i386.rpm
879f133178898835609ec305988b473e7221f825 
redhat/7.3/updates/i386/mysql-devel-3.23.58-1.73.5.legacy.i386.rpm
9258ee1dd63f878c376a4e8a4f28e6dc8be11600 
redhat/7.3/updates/i386/mysql-server-3.23.58-1.73.5.legacy.i386.rpm
f8dfbc8e8992bb56c1f8ba9f6917ab0fb11d0e80 
redhat/7.3/updates/SRPMS/mysql-3.23.58-1.73.5.legacy.src.rpm
246af76de738268375fee9c066efdabdc5a01f73 
redhat/9/updates/i386/mysql-3.23.58-1.90.5.legacy.i386.rpm
22b584c92e81cd29086fa2335910ba5b67d22711 
redhat/9/updates/i386/mysql-devel-3.23.58-1.90.5.legacy.i386.rpm
4fe21cae92371b5a3ed79858ec5432807bf2cee4 
redhat/9/updates/i386/mysql-server-3.23.58-1.90.5.legacy.i386.rpm
106480fe6f5d56513a4fd77592d5a8e88a9c4825 
redhat/9/updates/SRPMS/mysql-3.23.58-1.90.5.legacy.src.rpm
509f1caeef89bb626334be27e13c4269cc00ca75 
fedora/1/updates/i386/mysql-3.23.58-4.3.legacy.i386.rpm
7e0bf52038d1ccb3e56f8f2e48f32846e9cb52ec 
fedora/1/updates/i386/mysql-bench-3.23.58-4.3.legacy.i386.rpm
08c25d36193f30dceb4d3f81fbdd69f713fd94b7 
fedora/1/updates/i386/mysql-devel-3.23.58-4.3.legacy.i386.rpm
8fa58175f2d1baf7d45e8c19939928d3faa113ba 
fedora/1/updates/i386/mysql-server-3.23.58-4.3.legacy.i386.rpm
291ec6bb776126c3726dc7dfc067afad520300af 
fedora/1/updates/SRPMS/mysql-3.23.58-4.3.legacy.src.rpm

These packages are GPG signed by Fedora Legacy for security.  Our key is
available from http://www.fedoralegacy.org/about/security.php

You can verify each package with the following command:

     rpm --checksig -v <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the sha1sum with the following command:

     sha1sum <filename>

8. References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0381
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0388
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0457
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0835
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0836
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0837
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0957
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0004

9. Contact:

The Fedora Legacy security contact is <secnotice at fedoralegacy.org>. More
project details at http://www.fedoralegacy.org

---------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050324/5657436b/attachment.sig>

From marcdeslauriers at videotron.ca  Thu Mar 24 23:08:25 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Thu, 24 Mar 2005 18:08:25 -0500
Subject: [FLSA-2005:2268] Updated spamassassin package fixes security issues
Message-ID: <42434869.5080005@videotron.ca>

---------------------------------------------------------------------
                Fedora Legacy Update Advisory

Synopsis:          Updated spamassassin package fixes security issues
Advisory ID:       FLSA:2268
Issue date:        2005-03-24
Product:           Fedora Core
Keywords:          Bugfix
Cross references:  https://bugzilla.fedora.us/show_bug.cgi?id=2268
CVE Names:         CAN-2004-0796
---------------------------------------------------------------------


---------------------------------------------------------------------
1. Topic:

An updated spamassassin package that fixes a denial of service bug when
parsing malformed messages is now available.

SpamAssassin provides a way to reduce unsolicited commercial email
(SPAM) from incoming email.

2. Relevant releases/architectures:

Fedora Core 1 - i386

3. Problem description:

A denial of service bug has been found in SpamAssassin versions below
2.64. A malicious attacker could construct a message in such a way that
would cause spamassassin to stop responding, potentially preventing the
delivery or filtering of email. The Common Vulnerabilities and Exposures
project (cve.mitre.org) has assigned the name CAN-2004-0796 to this
issue.

Users of SpamAssassin should update to these updated packages which
contain a backported patch and is not vulnerable to this issue.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which
are not installed but included in the list will not be updated.  Note
that you can also use wildcards (*.rpm) if your current directory *only*
contains the desired RPMs.

Please note that this update is also available via yum and apt.  Many
people find this an easier way to apply updates.  To use yum issue:

yum update

or to use apt:

apt-get update; apt-get upgrade

This will start an interactive process that will result in the
appropriate RPMs being upgraded on your system.  This assumes that you
have yum or apt-get configured for obtaining Fedora Legacy content.
Please visit http://www.fedoralegacy.org/docs for directions on how to
configure yum and apt-get.

5. Bug IDs fixed:

http://bugzilla.fedora.us - bug #2268 - SpamAssassin Message Handling DoS

6. RPMs required:

Fedora Core 1:

SRPM:
http://download.fedoralegacy.org/fedora/1/updates/SRPMS/spamassassin-2.63-0.2.2.legacy.src.rpm

i386:
http://download.fedoralegacy.org/fedora/1/updates/i386/spamassassin-2.63-0.2.2.legacy.i386.rpm

7. Verification:

SHA1 sum                                 Package Name
---------------------------------------------------------------------

e76200ac598d6cb56ec18b92cfe6ce6af0181683 
fedora/1/updates/i386/spamassassin-2.63-0.2.2.legacy.i386.rpm
21e17d5e33e8ba6bf76c288544719169982bb415 
fedora/1/updates/SRPMS/spamassassin-2.63-0.2.2.legacy.src.rpm

These packages are GPG signed by Fedora Legacy for security.  Our key is
available from http://www.fedoralegacy.org/about/security.php

You can verify each package with the following command:

     rpm --checksig -v <filename>

If you only wish to verify that each package has not been corrupted or
tampered with, examine only the sha1sum with the following command:

     sha1sum <filename>

8. References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0796

9. Contact:

The Fedora Legacy security contact is <secnotice at fedoralegacy.org>. More
project details at http://www.fedoralegacy.org

---------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050324/bd131e78/attachment.sig>

From marcdeslauriers at videotron.ca  Thu Mar 24 23:26:32 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Thu, 24 Mar 2005 18:26:32 -0500
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <1111700039.3471.215.camel@jkeating2.hq.pogolinux.com>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<1111445092.28926.2.camel@mdlinux>
	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>
	<1111496949.14670.16.camel@mdlinux>
	<1111700039.3471.215.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1111706793.22036.20.camel@mdlinux>

On Thu, 2005-03-24 at 13:33 -0800, Jesse Keating wrote:
> Fedora Legacy will support TWO outdated Fedora releases at any time.
> 
> When FC4test2 releases, Red Hat will discontinue support for FC2 and
> Fedora Legacy will pick it up.  Nothing will happen to Fedora Core 1.
> Fedora is supporting FC4 and FC3, Legacy is supporting FC2 and FC1.
> Now, when FC5 Test2 releases, Red Hat will drop support for FC3.  Fedora
> Legacy picks up FC3 and drops FC1 from it's ranks.

This is exactly the kind of example we should have on our web page. It's
clear, concise, and easy to understand.

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050324/b2edf36d/attachment.sig>

From dsccable at comcast.net  Fri Mar 25 03:10:50 2005
From: dsccable at comcast.net (David Curry)
Date: Thu, 24 Mar 2005 22:10:50 -0500
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <1111700039.3471.215.camel@jkeating2.hq.pogolinux.com>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>	<423B6AAA.2020003@digitalhermit.com>	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>	<1111445092.28926.2.camel@mdlinux>	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>	<1111496949.14670.16.camel@mdlinux>
	<1111700039.3471.215.camel@jkeating2.hq.pogolinux.com>
Message-ID: <4243813A.909@comcast.net>

Jesse Keating wrote:

>On Tue, 2005-03-22 at 08:09 -0500, Marc Deslauriers wrote:
>  
>
>>Si in other words, Fedora Legacy will never maintain more than one
>>unsupported Fedora Core version? It seems to me that prolonging the
>>usefulness of a release by only six months isn't very long and, IMO, a
>>waste of time.
>>    
>>
>
>This is wrong.
>
>Fedora Legacy will support TWO outdated Fedora releases at any time.
>
>When FC4test2 releases, Red Hat will discontinue support for FC2 and
>Fedora Legacy will pick it up.  Nothing will happen to Fedora Core 1.
>Fedora is supporting FC4 and FC3, Legacy is supporting FC2 and FC1.
>Now, when FC5 Test2 releases, Red Hat will drop support for FC3.  Fedora
>Legacy picks up FC3 and drops FC1 from it's ranks.
>
>My initial estimate of 1.5 years was a bit low, as I was expecting
>faster FC releases than once every 6 months.  So I err'd on the side of
>short as it's always a better surprise when you get longer support than
>quoted (:
>
>With a 6-month release cycle, RH will support a given FC release for
>almost a year.  Then FC will pick it up and support it for almost
>another year.  Thats almost 2 years of support.  Perhaps we need to
>change the FAQ to say 'between 1.5 and 2 years'.
>
>  
>
Discussion of the support horizon for FC releases has raised a question 
or two.  FL continues to support RH 7.3 and RH9, but all discussion of 
support for FC releases has focused on finite time horizons.  Is the 
number of users wanting to stay with a particular release and help 
support it a criterion that will be factored into the support horizon.  
Or, will the FL support horizon for FC releases be strictly tied to Red 
Hat's FC release calendar?




From mattdm at mattdm.org  Fri Mar 25 04:30:03 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 24 Mar 2005 23:30:03 -0500
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <4243813A.909@comcast.net>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<1111445092.28926.2.camel@mdlinux>
	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>
	<1111496949.14670.16.camel@mdlinux>
	<1111700039.3471.215.camel@jkeating2.hq.pogolinux.com>
	<4243813A.909@comcast.net>
Message-ID: <20050325043003.GA3020@jadzia.bu.edu>

On Thu, Mar 24, 2005 at 10:10:50PM -0500, David Curry wrote:
> support it a criterion that will be factored into the support horizon.  
> Or, will the FL support horizon for FC releases be strictly tied to Red 
> Hat's FC release calendar?

Well, for what it's worth, we (BU) intend to maintain a FC2-based
distribution through summer 2006. And as I said before, to get a lot more
involved with Legacy.

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From rostetter at mail.utexas.edu  Fri Mar 25 04:39:23 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Thu, 24 Mar 2005 22:39:23 -0600
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <4243813A.909@comcast.net>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<1111445092.28926.2.camel@mdlinux>
	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>
	<1111496949.14670.16.camel@mdlinux>
	<1111700039.3471.215.camel@jkeating2.hq.pogolinux.com>
	<4243813A.909@comcast.net>
Message-ID: <1111725563.13aedce96d5c6@mail.ph.utexas.edu>

Quoting David Curry <dsccable at comcast.net>:

> Discussion of the support horizon for FC releases has raised a question
> or two.  FL continues to support RH 7.3 and RH9, but all discussion of
> support for FC releases has focused on finite time horizons.  Is the

Correct.  That is the way the project was created.

> number of users wanting to stay with a particular release and help
> support it a criterion that will be factored into the support horizon.

Only (as it stands now) in the sense that if there is not enough people
willing to help support a release, it will be dropped.

I can see where, if there is a lot of support for a particular release,
and people want it extended for a while, it could be done for a small
length of time.  But I'd hate to see it happen for more than just a
small period of time.

> Or, will the FL support horizon for FC releases be strictly tied to Red
> Hat's FC release calendar?

That's been the plan from day one, and so far no talk of changing it.
I don't think it would be feasible to change it, as I don't think we'll
ever have enough people to support more than about a half dozen or
so releases.

Of course, the above is my opinion only, and in no way official or anything.

-- 
Eric Rostetter



From jsauer at joesauer.org  Fri Mar 25 16:13:28 2005
From: jsauer at joesauer.org (Joe Sauer)
Date: Fri, 25 Mar 2005 08:13:28 -0800
Subject: mysql-server
Message-ID: <1111767208.5462.43.camel@spider.joesauer.org>

Did anyone else experience any mysql servers not restarting themselves
properly, after the mysql-server upgrade last night, and having to
manually restart mysqld?

Thanks 
-Joe
-- 



From jonny.strom at netikka.fi  Fri Mar 25 16:16:08 2005
From: jonny.strom at netikka.fi (Johnny Strom)
Date: Fri, 25 Mar 2005 18:16:08 +0200
Subject: mysql-server
In-Reply-To: <1111767208.5462.43.camel@spider.joesauer.org>
References: <1111767208.5462.43.camel@spider.joesauer.org>
Message-ID: <42443948.6090608@netikka.fi>

Joe Sauer wrote:
> Did anyone else experience any mysql servers not restarting themselves
> properly, after the mysql-server upgrade last night, and having to
> manually restart mysqld?
> 
> Thanks 
> -Joe



Well I stopped and started it manually before the uppgrade so I do not 
know about that issue.

But mysql seems to work just fine on a RH9 server with a lot of traffic 
all the time.


Thanks

   Johnny



From shurdeek at routehat.org  Fri Mar 25 16:23:25 2005
From: shurdeek at routehat.org (Peter Surda)
Date: Fri, 25 Mar 2005 17:23:25 +0100
Subject: mysql-server
In-Reply-To: <1111767208.5462.43.camel@spider.joesauer.org>
References: <1111767208.5462.43.camel@spider.joesauer.org>
Message-ID: <20050325162325.GH12881@soldats.localdomain>

On Fri, Mar 25, 2005 at 08:13:28AM -0800, Joe Sauer wrote:
> Did anyone else experience any mysql servers not restarting themselves
> properly, after the mysql-server upgrade last night, and having to
> manually restart mysqld?
I had experienced this several times in the past already, that's why I update
mysql manually. Coincidentally, one server I know had exactly this problem
last night, so you're not alone :-).

> Thanks 
> -Joe
Bye,

Peter Surda (Shurdeek) <shurdeek at routehat.org>, ICQ 10236103, +436505122023

-- 
           There are two kind of sysadmins: Paranoids and Losers



From ssharma at revsharecorp.com  Fri Mar 25 17:41:00 2005
From: ssharma at revsharecorp.com (Ajay Sharma)
Date: Fri, 25 Mar 2005 09:41:00 -0800
Subject: mysql-server
In-Reply-To: <1111767208.5462.43.camel@spider.joesauer.org>
References: <1111767208.5462.43.camel@spider.joesauer.org>
Message-ID: <42444D2C.4040404@revsharecorp.com>

Joe Sauer wrote:
> Did anyone else experience any mysql servers not restarting themselves
> properly, after the mysql-server upgrade last night, and having to
> manually restart mysqld?

I'm not sure why but mysql never restarted after an update, even from
the "official" Redhat updates.  I guess the thinking was that they
didn't want to shutdown a running server in the middle of a query?  But
it's kinda pointless because the mysql server is pretty much busted
after you install the RPM.  You *need* the restart to make it work.

In any case, install the mysql-server manually just like the kernel.  :)

--Ajay



From s.traylen at rl.ac.uk  Fri Mar 25 21:24:12 2005
From: s.traylen at rl.ac.uk (Steve Traylen)
Date: Fri, 25 Mar 2005 21:24:12 +0000
Subject: mysql-server
In-Reply-To: <42444D2C.4040404@revsharecorp.com>
References: <1111767208.5462.43.camel@spider.joesauer.org>
	<42444D2C.4040404@revsharecorp.com>
Message-ID: <20050325212412.GB10837@x.esc.rl.ac.uk>

On Fri, Mar 25, 2005 at 09:41:00AM -0800 or thereabouts, Ajay Sharma wrote:
> Joe Sauer wrote:
> > Did anyone else experience any mysql servers not restarting themselves
> > properly, after the mysql-server upgrade last night, and having to
> > manually restart mysqld?
> 
> I'm not sure why but mysql never restarted after an update, even from
> the "official" Redhat updates.  I guess the thinking was that they
> didn't want to shutdown a running server in the middle of a query?  But
> it's kinda pointless because the mysql server is pretty much busted
> after you install the RPM.  You *need* the restart to make it work.
> 
> In any case, install the mysql-server manually just like the kernel.  :)

Hi  Ajay,

  I noted this with the  MySQL upgrade and I did add a bug report to 
  Redhat but I can not find it anywhere in bugzilla there now....

  In the init.d script there is a line that looks something like

  ping="mysqladmin ........" 

  if you add  a '-t 2' with in this command then you should hopefully
  have more success starting up MySQL.

      Steve



     Steve
> 
> --Ajay
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list

-- 
Steve Traylen
s.traylen at rl.ac.uk
http://www.gridpp.ac.uk/



From ad+lists at uni-x.org  Fri Mar 25 21:33:28 2005
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Fri, 25 Mar 2005 22:33:28 +0100
Subject: mysql-server
In-Reply-To: <20050325212412.GB10837@x.esc.rl.ac.uk>
References: <1111767208.5462.43.camel@spider.joesauer.org>
	<42444D2C.4040404@revsharecorp.com>
	<20050325212412.GB10837@x.esc.rl.ac.uk>
Message-ID: <1111786407.11539.117.camel@serendipity.dogma.lan>

Am Fr, den 25.03.2005 schrieb Steve Traylen um 22:24:

>   I noted this with the  MySQL upgrade and I did add a bug report to 
>   Redhat but I can not find it anywhere in bugzilla there now....
> 
>   In the init.d script there is a line that looks something like
> 
>   ping="mysqladmin ........" 
> 
>   if you add  a '-t 2' with in this command then you should hopefully
>   have more success starting up MySQL.
> 
>       Steve

That is not really a fix. The issue is, that the init script does not
take care for the case, that the MySQL root user has a password set
(which is highly recommended) and the anonymous user removed.
Unfortunately the RPM install does not care for a changed init script -
changed for fixing the issue - and exchanges it with the wrong one
again.

In the /etc/init.d/mysqld init script there are 2 lines with a
"mysqladmin ping ..." command. Change it to be

if [ -n "`/usr/bin/mysqladmin ping -u DUMMY_USER 2> /dev/null`" ]; then

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.770_FC2smp 
Serendipity 22:30:16 up 8 days, 20:26, load average: 0.61, 0.66, 0.57 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050325/be592dd1/attachment.sig>

From s.traylen at rl.ac.uk  Fri Mar 25 23:51:24 2005
From: s.traylen at rl.ac.uk (Steve Traylen)
Date: Fri, 25 Mar 2005 23:51:24 +0000
Subject: mysql-server
In-Reply-To: <1111786407.11539.117.camel@serendipity.dogma.lan>
References: <1111767208.5462.43.camel@spider.joesauer.org>
	<42444D2C.4040404@revsharecorp.com>
	<20050325212412.GB10837@x.esc.rl.ac.uk>
	<1111786407.11539.117.camel@serendipity.dogma.lan>
Message-ID: <20050325235124.GA11404@x.esc.rl.ac.uk>

On Fri, Mar 25, 2005 at 10:33:28PM +0100 or thereabouts, Alexander Dalloz wrote:
> Am Fr, den 25.03.2005 schrieb Steve Traylen um 22:24:
> 
> >   I noted this with the  MySQL upgrade and I did add a bug report to 
> >   Redhat but I can not find it anywhere in bugzilla there now....
> > 
> >   In the init.d script there is a line that looks something like
> > 
> >   ping="mysqladmin ........" 
> > 
> >   if you add  a '-t 2' with in this command then you should hopefully
> >   have more success starting up MySQL.
> > 
> >       Steve
> 
> That is not really a fix. The issue is, that the init script does not
> take care for the case, that the MySQL root user has a password set
> (which is highly recommended) and the anonymous user removed.
> Unfortunately the RPM install does not care for a changed init script -
> changed for fixing the issue - and exchanges it with the wrong one
> again.

I know it is not a fix, just the easiest thing to do to remove the
problem I could find. At this time that is my only interest.
> 
> In the /etc/init.d/mysqld init script there are 2 lines with a
> "mysqladmin ping ..." command. Change it to be
> 
> if [ -n "`/usr/bin/mysqladmin ping -u DUMMY_USER 2> /dev/null`" ]; then
> 
> Alexander
> 
> 
> -- 
> Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
> legal statement: http://www.uni-x.org/legal.html
> Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.770_FC2smp 
> Serendipity 22:30:16 up 8 days, 20:26, load average: 0.61, 0.66, 0.57 



> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list

-- 
Steve Traylen
s.traylen at rl.ac.uk
http://www.gridpp.ac.uk/



From marcdeslauriers at videotron.ca  Fri Mar 25 23:54:53 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Fri, 25 Mar 2005 18:54:53 -0500
Subject: Fedora Legacy Test Update Notification: squid
Message-ID: <4244A4CD.802@videotron.ca>

---------------------------------------------------------------------
Fedora Legacy Test Update Notification
FEDORALEGACY-2005-2150
Bugzilla https://bugzilla.fedora.us/show_bug.cgi?id=2150
2005-03-25
---------------------------------------------------------------------

Name        : squid
Versions    : rh7.3: squid-2.4.STABLE7-0.73.2.legacy
Versions    : rh9: squid-2.5.STABLE1-9.9.legacy
Versions    : fc1: squid-2.5.STABLE3-2.fc1.5.legacy
Summary     : The Squid proxy caching server.
Description :
Squid is a high-performance proxy caching server for Web clients,
supporting FTP, gopher, and HTTP data objects. Unlike traditional
caching software, Squid handles all requests in a single,
non-blocking, I/O-driven process. Squid keeps meta data and especially
hot objects cached in RAM, caches DNS lookups, supports non-blocking
DNS lookups, and implements negative caching of failed requests.

Squid consists of a main server program squid, a Domain Name System
lookup program (dnsserver), a program for retrieving FTP data
(ftpget), and some management and client tools.

---------------------------------------------------------------------
Update Information:

An updated Squid package that fixes several security issues is now
available.

Squid is a full-featured Web proxy cache.

A buffer overflow was found within the NTLM authentication helper
routine. If Squid is configured to use the NTLM authentication helper,
a remote attacker could potentially execute arbitrary code by sending a
lengthy password. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2004-0541 to this issue.

An out of bounds memory read bug was found within the NTLM
authentication helper routine. If Squid is configured to use the NTLM
authentication helper, a remote attacker could send a carefully crafted
NTLM authentication packet and cause Squid to crash. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-0832 to this issue.

iDEFENSE reported a flaw in the squid SNMP module. This flaw could allow
an attacker who has the ability to send arbitrary packets to the SNMP
port to restart the server, causing it to drop all open connections. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0918 to this issue.

A buffer overflow flaw was found in the Gopher relay parser. This bug
could allow a remote Gopher server to crash the Squid proxy that reads
data from it. Although Gopher servers are now quite rare, a malicious
web page (for example) could redirect or contain a frame pointing to an
attacker's malicious gopher server. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2005-0094 to
this issue.

An integer overflow flaw was found in the WCCP message parser. It is
possible to crash the Squid server if an attacker is able to send a
malformed WCCP message with a spoofed source address matching Squid's
"home router". The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2005-0095 to this issue.

A memory leak was found in the NTLM fakeauth_auth helper. It is possible
that an attacker could place the Squid server under high load, causing
the NTML fakeauth_auth helper to consume a large amount of memory,
resulting in a denial of service. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2005-0096 to
this issue.

A NULL pointer de-reference bug was found in the NTLM fakeauth_auth
helper. It is possible for an attacker to send a malformed NTLM type 3
message, causing the Squid server to crash. The Common Vulnerabilities
and Exposures project (cve.mitre.org) has assigned the name
CAN-2005-0097 to this issue.

A username validation bug was found in squid_ldap_auth. It is possible
for a username to be padded with spaces, which could allow a user to
bypass explicit access control rules or confuse accounting. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2005-0173 to this issue.

The way Squid handles HTTP responses was found to need strengthening. It
is possible that a malicious web server could send a series of HTTP
responses in such a way that the Squid cache could be poisoned,
presenting users with incorrect webpages. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the names CAN-2005-0174
and CAN-2005-0175 to these issues.

When processing the configuration file, Squid parses empty Access
Control Lists (ACLs) and proxy_auth ACLs without defined auth schemes in
a way that effectively removes arguments, which could allow remote
attackers to bypass intended ACLs. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2005-0194 to
this issue.

A buffer overflow bug was found in the WCCP message parser. It is
possible that an attacker could send a malformed WCCP message which
could crash the Squid server or execute arbitrary code. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2005-0211 to this issue.

A bug was found in the way Squid handled oversized HTTP response
headers. It is possible that a malicious web server could send a
specially crafted HTTP header which could cause the Squid cache to be
poisoned, presenting users with incorrect webpages. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2005-0241 to this issue.

A bug was found in the way Squid handles FQDN lookups. It was possible
to crash the Squid server by sending a carefully crafted DNS response to
an FQDN lookup. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2005-0446 to this issue.

A race condition was discovered in the handling of "Set-Cookie" headers.
If the obsolete Netscape recommendation was used for handling cookies in
the cache, it was possible for an attacker to steal the cookies of other
users. The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CAN-2005-0626 to this issue.

Users of Squid should upgrade to this updated package, which contains
backported patches, and is not vulnerable to these issues.

---------------------------------------------------------------------
Changelogs

rh73:
* Sat Mar 19 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7:2.4.STABLE7-0.73.2.legacy
- Added security patch for CAN-2005-0446 taken from RHEL3
- Added backported security patch for CAN-2005-0626

* Wed Feb 16 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7:2.4.STABLE7-0.73.1.legacy
- Rebuilt as Fedora Legacy security update for Red Hat Linux 7.3

* Tue Feb 01 2005 Jay Fenlason <fenlason at redhat.com>
- Two more security fixes:
   * CAN-2005-0211 bz#146777 buffer overflow in wccp recvfrom() call
   * bz#146780 correct handling of oversize reply headers

* Mon Jan 31 2005 Jay Fenlason <fenlason at redhat.com>
- Change the squid user's login shell to /sbin/nologin

* Mon Jan 31 2005 Jay Fenlason <fenlason at redhat.com> 7:2.4.STABLE7-1.21as.3
- Don't include the 0-length files created by patch in the errors directory.

* Fri Jan 28 2005 Jay Fenlason <fenlason at redhat.com> 7:2.4.STABLE7-1.21as.2
- Backport three more security fixes to close bz#146159
- Also backport the -reply_header_max_size patch
- Reorganize this spec file to apply upstream patches first.

* Thu Jan 20 2005 Jay Fenlason <fenlason at redhat.com> 7:2.4.STABLE7-1.21as.1
- Backport fixes for CAN-2005-0094 (remote DOS in parsing malformed Gopher
   messages). and CAN-2005-0095 (remote DOS in parsing malformed wccp 
messages).
- This version of squid is not vulnerable to CAN-2005-0096 and CAN-2005-0097
   because it does not contain the ntlm_auth helper.

* Tue Oct 12 2004 Jay Fenlason <fenlason at redhat.com> 7:2.4.STABLE7-1.21as
- Backport SNMP_core_dump patch from 2.5.STABLE6 to fix CAN-2004-0918
   (Remote DoS)

* Mon Jun 21 2004 Jay Fenlason <fenlason at redhat.com> 7:2.4.STABLE7-0.21as
- bump to 2.4.STABLE7 to pick up all the post STABLE6 patches
- Include the three upstream patches to 2.4.STABLE7
- Add the forward_retries one-line patch for bugzilla #120849

rh9:
* Fri Mar 18 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7:2.5.STABLE1-9.9.legacy
- Added security patch for CAN-2005-0446 taken from RHEL3
- Added backported security patch for CAN-2005-0626

* Sat Feb 19 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7:2.5.STABLE1-8.9.legacy
- Added openssl-devel and cyrus-sasl-devel BuildPrereq

* Wed Feb 16 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7:2.5.STABLE1-7.9.legacy
- Security patches for CAN-2005-0094, CAN-2005-0095, CAN-2005-0096,
   CAN-2005-0097, CAN-2005-0173, CAN-2005-0174, CAN-2005-0175,
   CAN-2005-0194, CAN-2005-0211, CAN-2005-0241

* Sat Oct 16 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7:2.5.STABLE1-6.9.legacy
- CAN-2004-0918 security patch (snmp DoS)

* Fri Sep 10 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7:2.5.STABLE1-5.9.legacy
- CAN-2004-0832 security patch (malformed NTLMSSP packets crash NTLM 
helpers)

* Tue Jun 08 2004 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7:2.5.STABLE1-4.9.legacy
- CAN-2004-0541 security patch (NTLM Authentication Helper Buffer Overflow)

fc1:
* Sat Mar 19 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7:2.5.STABLE3-2.fc1.5.legacy
- Added security patch for CAN-2005-0446 taken from RHEL3
- Added backported security patch for CAN-2005-0626

* Sun Feb 20 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7:2.5.STABLE3-2.fc1.4.legacy
- Added missing openssl-devel and cyrus-sasl-devel BuildPrereq

* Wed Feb 16 2005 Marc Deslauriers <marcdeslauriers at videotron.ca> 
7:2.5.STABLE3-2.fc1.3.legacy
- Security patches for CAN-2005-0094, CAN-2005-0095, CAN-2005-0096,
   CAN-2005-0097, CAN-2005-0173, CAN-2005-0174, CAN-2005-0175,
   CAN-2005-0194, CAN-2005-0211, CAN-2005-0241

* Tue Oct 12 2004 Rob Myers <rob.myers at gtri.gatech.edu> 
7:2.5.STABLE3-2.fc1.2.legacy
- apply patch for CAN-2004-0918 bug #2150
- group last patch under fedora legacy security updates

* Tue Oct 05 2004 Rob Myers <rob.myers at gtri.gatech.edu> 
7:2.5.STABLE3-2.fc1.1.legacy
- apply patch from 2.5.STABLE3-1.fc1 RHEL3 for CAN-2004-0832

---------------------------------------------------------------------
This update can be downloaded from:
   http://download.fedoralegacy.org/
(sha1sums)

rh7.3:
bc2ae2612ca458e900d7088c3f7b5dc354fd43b7 
redhat/7.3/updates-testing/i386/squid-2.4.STABLE7-0.73.2.legacy.i386.rpm
adc8920bddb66fd0726dba6840fa1052d7cf2e1b 
redhat/7.3/updates-testing/SRPMS/squid-2.4.STABLE7-0.73.2.legacy.src.rpm

rh9:
6babebc4cc24afe9341d04bfc876b82629b8465e 
redhat/9/updates-testing/i386/squid-2.5.STABLE1-9.9.legacy.i386.rpm
a83008420aa911d27948c25d91b0f692dfb12754 
redhat/9/updates-testing/SRPMS/squid-2.5.STABLE1-9.9.legacy.src.rpm

fc1:
339131d68c1658cf1d0c5faff9afcb5b9723bfca 
fedora/1/updates-testing/i386/squid-2.5.STABLE3-2.fc1.5.legacy.i386.rpm
1c7fdc3a29fc96097fb9ef640a1c426aa600f9d5 
fedora/1/updates-testing/SRPMS/squid-2.5.STABLE3-2.fc1.5.legacy.src.rpm

---------------------------------------------------------------------

Please test and comment in bugzilla.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050325/098a528a/attachment.sig>

From Axel.Thimm at ATrpms.net  Sat Mar 26 22:31:50 2005
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sat, 26 Mar 2005 23:31:50 +0100
Subject: Mirroring: Bad datestamps prevent hardlinking
Message-ID: <20050326223150.GB5752@neu.nirvana>

Could the parts that are mirrored from Red Hat be timestamped back to
their original values? For instance:

58217 Oct 29  2003 download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/ncompress-4.2.4-34.src.rpm
58217 Feb 27  2004 download.fedoralegacy.org/fedora/1/os/SRPMS/ncompress-4.2.4-34.src.rpm

This would allow mirrors of both RH and FL to run hardlink over the
folders and rescue some bits.

Thanks.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050326/376a30f9/attachment.sig>

From brian.t.brunner at gai-tronics.com  Mon Mar 28 19:41:17 2005
From: brian.t.brunner at gai-tronics.com (Brian T. Brunner)
Date: Mon, 28 Mar 2005 11:41:17 -0800
Subject: Numbering conventions
Message-ID: <s247ed69.013@CRPSPKWANW02-IA.hubbell.com>


Yes, the version numbering reads from left-to-right
2.4.20.99 is before 2.4.21.1

'legacy' indicates it is from the fedora-legacy project; progeny is unknown 
to me except an ISP brand name.

athlon. vs i386 vs <none> indicates whether the rpm is built on/for a particular 
architecture.  .i386 runs anywhere (tm) but .athlon is not guaranteed on i686 or 
x64 architecture.

Brian Brunner
brian.t.brunner at gai-tronics.com
(610)796-5838

>>> fedoraleg_form at mm-vanecek.cc 03/28/05 01:51PM >>>
I am getting a little confused about the numbering conventions.

For example, how does (if it does)

kernel-2.4.20-31.9.progeny.7.athlon.rpm

compare with 

kernel-2.4.20-42.9.legacy.athlon.rpm?

Can I assume that the legacy version is a more current version than the progeny? 

Thanks.

--
fedora-legacy-list mailing list
fedora-legacy-list at redhat.com 
http://www.redhat.com/mailman/listinfo/fedora-legacy-list

*******************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept
for the presence of computer viruses.

www.hubbell.com - Hubbell Incorporated



From hbo at egbok.com  Mon Mar 28 19:55:04 2005
From: hbo at egbok.com (Howard Owen)
Date: Mon, 28 Mar 2005 11:55:04 -0800
Subject: Numbering conventions
In-Reply-To: <s247ed69.013@CRPSPKWANW02-IA.hubbell.com>
References: <s247ed69.013@CRPSPKWANW02-IA.hubbell.com>
Message-ID: <1112039704.11654.40.camel@Quirk.egbok.com>

Progeny is the Linux systems company founded by Ian Murdock of Debian
fame. They run a "transition service" for RH 7.2 7.3, 8 and 9. Their
numbering scheme is name-base-version.progeny.n .. So the indicated
kernel:

	kernel-2.4.20-31.9.progeny.7.athlon.rpm

is the 7th Progeny patch to the base RHL 9 kernel. There is no way to
easily compare this with the legacy kernels, because they are the
product of two different patching processes. The only way to tell is to
grab the source RPMs and compare the patches between the two. It's
likely that they have chosen similar approaches to similar problems,
just as it's likely that they have diverged on some. 


On Mon, 2005-03-28 at 11:41 -0800, Brian T. Brunner wrote:
> Yes, the version numbering reads from left-to-right
> 2.4.20.99 is before 2.4.21.1
> 
> 'legacy' indicates it is from the fedora-legacy project; progeny is unknown 
> to me except an ISP brand name.
> 
> athlon. vs i386 vs <none> indicates whether the rpm is built on/for a particular 
> architecture.  .i386 runs anywhere (tm) but .athlon is not guaranteed on i686 or 
> x64 architecture.
> 
> Brian Brunner
> brian.t.brunner at gai-tronics.com
> (610)796-5838
> 
> >>> fedoraleg_form at mm-vanecek.cc 03/28/05 01:51PM >>>
> I am getting a little confused about the numbering conventions.
> 
> For example, how does (if it does)
> 
> kernel-2.4.20-31.9.progeny.7.athlon.rpm
> 
> compare with 
> 
> kernel-2.4.20-42.9.legacy.athlon.rpm?
> 
> Can I assume that the legacy version is a more current version than the progeny? 
> 
> Thanks.
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com 
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
> 
> *******************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> 
> This footnote also confirms that this email message has been swept
> for the presence of computer viruses.
> 
> www.hubbell.com - Hubbell Incorporated
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
> 
-- 
Howard Owen        hbo at egbok.com "Even if you are on the right
EGBOK Consultants Linux Architect track, you'll get run over if you
fwd:50279    pstn:+1-650-218-2216 just sit there." - Will Rogers



From hbo at egbok.com  Tue Mar 29 01:08:11 2005
From: hbo at egbok.com (Howard Owen)
Date: Mon, 28 Mar 2005 17:08:11 -0800
Subject: Numbering conventions
In-Reply-To: <20050329003855.M68939@mm-vanecek.cc>
References: <s247ed69.013@CRPSPKWANW02-IA.hubbell.com>
	<1112039704.11654.40.camel@Quirk.egbok.com>
	<20050329003855.M68939@mm-vanecek.cc>
Message-ID: <1112058491.30243.6.camel@owen.egbok.com>

Unless you want to dig in and understand what patches are being applied
in detail, I'd really recommend against doing that. I'd stick with one
or the other for consistency's sake. It's possible that an assumption
made in one package, the kernel say, could be coupled with a userland
change, in the NFS client stuff, for instance. If you have the kernel
from one project and the userland from another, you could have a
problem. 

I don't know of a specific instance where this is true for either the
Progeny or FL patches, so it may just be normal sysadmin paranoia. But
I'd worry about it if they were my servers.

On Mon, 2005-03-28 at 18:44 -0600, Mike Vanecek wrote:
> On Mon, 28 Mar 2005 11:55:04 -0800, Howard Owen wrote
> > Progeny is the Linux systems company founded by Ian Murdock of Debian
> > fame. They run a "transition service" for RH 7.2 7.3, 8 and 9. Their
> > numbering scheme is name-base-version.progeny.n .. So the indicated
> > kernel:
> > 
> > 	kernel-2.4.20-31.9.progeny.7.athlon.rpm
> > 
> > is the 7th Progeny patch to the base RHL 9 kernel. There is no way to
> > easily compare this with the legacy kernels, because they are the
> > product of two different patching processes. The only way to tell is 
> > to grab the source RPMs and compare the patches between the two. 
> > It's likely that they have chosen similar approaches to similar 
> > problems, just as it's likely that they have diverged on some.
> 
> That is what I thought, but wanted someone else's feedback. Progeny sometimes
> has updates not available via legacy. Hence, my approach has been legacy first
> and progeny second. Progeny had just released their newest kernel whereas the
> legacy one was released in Feb. However, even if I force install the progeny
> version, yum is going to want to install the current legacy version. Things do
> not seem to be broke, I think I will just let them be.
> 
> Thank you.
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
> 
-- 
Howard Owen        hbo at egbok.com "Even if you are on the right
EGBOK Consultants Linux Architect track, you'll get run over if you
fwd:50279    pstn:+1-650-218-2216 just sit there." - Will Rogers



From mattdm at mattdm.org  Tue Mar 29 14:47:37 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 29 Mar 2005 09:47:37 -0500
Subject: state of bugzilla (and, current kernel root exploits....)
Message-ID: <20050329144737.GA17121@jadzia.bu.edu>

I'm trying to track the issues from Fedora alert FEDORA-2005-262,
particularly CAN-2005-0750, which is a local root exploit. But I'm confused.
What's the state of bugzilla for FL issues right now?


-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From ismanager at ccbnpts.com  Tue Mar 29 17:11:17 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Tue, 29 Mar 2005 11:11:17 -0600
Subject: mysql-server
In-Reply-To: <1111767208.5462.43.camel@spider.joesauer.org>
Message-ID: <006301c53482$52d63510$7202a8c0@ccb2vpjza>

> 
> Did anyone else experience any mysql servers not restarting themselves
> properly, after the mysql-server upgrade last night, and having to
> manually restart mysqld?
> 
> Thanks 
> -Joe

Yep, I had two mySQL services choke after the updates. Doing a manual
restart did the trick and all was well.

One thing I'd like to point out. Considering that many (all?) of us are
using the Fedora Legacy updates in an automatic mode, care should be
taken releasing an update for a major package on a holiday weekend. This
past Friday was Good Friday and though not an "official" holiday it is
common for many companies (mainly nonprofits) to take that day off. It's
also a prime day for people to take a day of vacation (if they aren't
already off). Releasing major updates on any major federal / religious
holiday is, IMHO, a bad idea. Releasing them on weekends can also be
just as bad.

Just some thoughts. Thanks all for the great work. :)

Paul Pettit
CTO and IS Manager
Consistent Computer Bargains Inc.

I've heard it said that the proof of lunacy is when you repeat the same
steps expecting different results.  I say it's proof that you're a
Microsoft user. - comment by deshi777 on experts-exchange.com



From rostetter at mail.utexas.edu  Tue Mar 29 17:23:48 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue, 29 Mar 2005 11:23:48 -0600
Subject: mysql-server
In-Reply-To: <006301c53482$52d63510$7202a8c0@ccb2vpjza>
References: <006301c53482$52d63510$7202a8c0@ccb2vpjza>
Message-ID: <1112117028.13b0c59e3f800@mail.ph.utexas.edu>

Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:

> One thing I'd like to point out. Considering that many (all?) of us are
> using the Fedora Legacy updates in an automatic mode, care should be

No, please don't use automatic updates on a production server.  It is
fine if you want to do it on a desktop machine or something, but don't
do this on a production server or important machine!

> taken releasing an update for a major package on a holiday weekend. This

We will get complaints if our releases are delayed for any reason, even
a holiday.  Number one complaint about FL is time to get a release out.
Delaying them by 3-4 (or more) days for holidays will not help.

> past Friday was Good Friday and though not an "official" holiday it is
> common for many companies (mainly nonprofits) to take that day off. It's
> also a prime day for people to take a day of vacation (if they aren't
> already off). Releasing major updates on any major federal / religious
> holiday is, IMHO, a bad idea. Releasing them on weekends can also be
> just as bad.

See above.

I only agree with not releasing updates on holidays/weekends when it is
an update for an unknown, unpublished, unexploited problem.  If the bug
is already know or being exploited, we need to get the update out asap.

The real issue here is that you should *NOT* do auto-updates on 
production (or critical) machines, ever, period.

> Just some thoughts. Thanks all for the great work. :)
 
> Paul Pettit
> CTO and IS Manager
> Consistent Computer Bargains Inc.

-- 
Eric Rostetter



From madlists at teaparty.net  Tue Mar 29 17:30:08 2005
From: madlists at teaparty.net (Tom Yates)
Date: Tue, 29 Mar 2005 18:30:08 +0100 (BST)
Subject: mysql-server
In-Reply-To: <1112117028.13b0c59e3f800@mail.ph.utexas.edu>
References: <006301c53482$52d63510$7202a8c0@ccb2vpjza>
	<1112117028.13b0c59e3f800@mail.ph.utexas.edu>
Message-ID: <Pine.LNX.4.61.0503291826140.24265@risby.gatekeeper.ltd.uk>

On Tue, 29 Mar 2005, Eric Rostetter wrote:

> Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:
> 
> > past Friday was Good Friday and though not an "official" holiday it is
> > common for many companies (mainly nonprofits) to take that day off. It's
> > also a prime day for people to take a day of vacation (if they aren't
> > already off). Releasing major updates on any major federal / religious
> > holiday is, IMHO, a bad idea. Releasing them on weekends can also be
> > just as bad.
[...] 
> I only agree with not releasing updates on holidays/weekends when it is
> an update for an unknown, unpublished, unexploited problem.  If the bug
> is already know or being exploited, we need to get the update out asap.

what's so special about federal holidays?  many FL users are outside the 
US.  are we going to interdict all public holidays everywhere?  or add 
localised holiday-handling code to yum?

in all cases, we should release as soon as we have something that (a) 
fixes the problem and (b) passes QA, and let the end-user decide how they 
would like to handle the released code.

> The real issue here is that you should *NOT* do auto-updates on 
> production (or critical) machines, ever, period.

i completely agree, and that's the only way i'd ever consider upgrading 
mine.


-- 

   Tom Yates
   Cambridge, UK.



From bedouglas at earthlink.net  Tue Mar 29 17:41:48 2005
From: bedouglas at earthlink.net (bruce)
Date: Tue, 29 Mar 2005 09:41:48 -0800
Subject: using yum to upgrade/install an FC2-> FC3 app
Message-ID: <025901c53486$964fa070$0301a8c0@Mesa.com>

hi...

i have mysql (FC2) on an FC2 machine. I'd like to install/upgrade to mysql
(FC3). however using rpm -Uvh 'blah' gives the usual dependency issues...

what's the best/correct way to upgrade/install to the FC3 mysql? would yum
be the best approach? if i force the install, i'm concerned that i'll break
the setup...

what's the best/correct way to do this...??

i'm trying to go from mysql (FC2) --> mysql (FC3)

thanks

bruce




From ismanager at ccbnpts.com  Tue Mar 29 17:48:28 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Tue, 29 Mar 2005 11:48:28 -0600
Subject: mysql-server
In-Reply-To: <Pine.LNX.4.61.0503291826140.24265@risby.gatekeeper.ltd.uk>
Message-ID: <007601c53487$83b9d330$7202a8c0@ccb2vpjza>

> Tom Yates wrote:
> 
> On Tue, 29 Mar 2005, Eric Rostetter wrote:
> 
> > Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:
> > 
> > > past Friday was Good Friday and though not an "official" 
> holiday it is
> > > common for many companies (mainly nonprofits) to take 
> that day off. It's
> > > also a prime day for people to take a day of vacation (if 
> they aren't
> > > already off). Releasing major updates on any major 
> federal / religious
> > > holiday is, IMHO, a bad idea. Releasing them on weekends 
> can also be
> > > just as bad.
> [...] 
> > I only agree with not releasing updates on 
> holidays/weekends when it is
> > an update for an unknown, unpublished, unexploited problem. 
>  If the bug
> > is already know or being exploited, we need to get the 
> update out asap.
> 
> what's so special about federal holidays?  many FL users are 
> outside the 
> US.  are we going to interdict all public holidays 
> everywhere?  or add 
> localised holiday-handling code to yum?
> 

I was using the term "federal" in it's broadest terms. Guess I should
have used the word "government" instead ... or would you have taken
offence to that too?

Please try and not start some kind of 'them vs us' fight where there was
none intended.


> in all cases, we should release as soon as we have something that (a) 
> fixes the problem and (b) passes QA, and let the end-user 
> decide how they 
> would like to handle the released code.
> 

And how I handle it is obviously not too important here.

Since there is no way to cache the downloads for implienting manually I
guess I'm SOL.


> > The real issue here is that you should *NOT* do auto-updates on 
> > production (or critical) machines, ever, period.
> 
> i completely agree, and that's the only way i'd ever consider 
> upgrading 
> mine.
> 

I'm glad.

I don't want to go to each and every machine (I have more than 1) and
manually run yum to update them. It defeats the purpose of having cron.
In fact Fedora Legacy's own documentation has a specific step for adding
automatic updates (step 4 - 7.3 documentation). There is no mention that
this process is NOT recommended by FL nor would I expect one. To limit
people to manually acting on updates devalues FL's service below
Microsoft.

As I seem to be a minority I will shut up now. Still I appriciate the
work put into the updates.

Paul Pettit

p.s. fedoralegacy.org is refusing connections. :(



From bedouglas at earthlink.net  Tue Mar 29 18:23:02 2005
From: bedouglas at earthlink.net (bruce)
Date: Tue, 29 Mar 2005 10:23:02 -0800
Subject: dependeny issues.... upgrading apps
Message-ID: <027901c5348c$59194020$0301a8c0@Mesa.com>

hi...

i'm looking to install/upgrade mysql (FC2->FC3) on a FC2 system. (i need the
additional functionality and thought i'd try to use the rpms that were
created for FC3.)

my question concerns the dependency issues that i get when i try to install
thngs like the kerebos libs. if i write over these libs with an updated
version, will other apps complain??

how can i go about doing an upgrade of an app, without having to upgrade the
entire OS??

thanks

bruce




From rostetter at mail.utexas.edu  Tue Mar 29 18:35:17 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue, 29 Mar 2005 12:35:17 -0600
Subject: mysql-server
In-Reply-To: <Pine.LNX.4.61.0503291826140.24265@risby.gatekeeper.ltd.uk>
References: <006301c53482$52d63510$7202a8c0@ccb2vpjza>
	<1112117028.13b0c59e3f800@mail.ph.utexas.edu>
	<Pine.LNX.4.61.0503291826140.24265@risby.gatekeeper.ltd.uk>
Message-ID: <1112121317.6f5f563401a6d@mail.ph.utexas.edu>

Quoting Tom Yates <madlists at teaparty.net>:

> > I only agree with not releasing updates on holidays/weekends when it is
> > an update for an unknown, unpublished, unexploited problem.  If the bug
> > is already know or being exploited, we need to get the update out asap.
> 
> what's so special about federal holidays?

The thread up to this point made no mention of federal holidays.  You're
just muddling the issue by introducing it now.

> many FL users are outside the
> US.  are we going to interdict all public holidays everywhere?  or add
> localised holiday-handling code to yum?

Code to yum would only be of benefit if it only applied to automatic
runs (otherwise it would interfer with those wishing to install updates
or test updates on the "restricted" days).  I don't think that would be
practical in any case.
 
> in all cases, we should release as soon as we have something that (a)
> fixes the problem and (b) passes QA, and let the end-user decide how they
> would like to handle the released code.

You're missing the point about my position.  If the bug is unknown, then
releasing it anounces the bug before people can patch.  If it is unreasonable
to assume the majority of people can patch it before an exploit appears
(which may happen immediately after announcing the fix), it would
be irresponsible to release the patch/update.

Now, if it went through a public QA, then the bug is already known, and
it can be released asap.  The only exception would be if it went through
a non-public QA.  This is unlikely to happen in FL, and is hence probably
not of concern.  It could be an issue for FL if we have "secret" patches
which are released without public QA due to the vendorsec (I think that's
the name?) agreement, but so far Jesse seems to think even vendorsec
stuff would probally go through public QA (or at least he posed the
question of whether it should).

> > The real issue here is that you should *NOT* do auto-updates on
> > production (or critical) machines, ever, period.
> 
> i completely agree, and that's the only way i'd ever consider upgrading
> mine.
> 
> 
> --
> 
>    Tom Yates
>    Cambridge, UK.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Tue Mar 29 18:42:04 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue, 29 Mar 2005 12:42:04 -0600
Subject: mysql-server
In-Reply-To: <1112121317.6f5f563401a6d@mail.ph.utexas.edu>
References: <006301c53482$52d63510$7202a8c0@ccb2vpjza>
	<1112117028.13b0c59e3f800@mail.ph.utexas.edu>
	<Pine.LNX.4.61.0503291826140.24265@risby.gatekeeper.ltd.uk>
	<1112121317.6f5f563401a6d@mail.ph.utexas.edu>
Message-ID: <1112121724.ccafe9193ba6b@mail.ph.utexas.edu>

Quoting Eric Rostetter <rostetter at mail.utexas.edu>:

> The thread up to this point made no mention of federal holidays.  You're
> just muddling the issue by introducing it now.

I take that back.  It did use the phrase "major federal / religious holidays."

I apologize for getting it wrong, and assigning blame where it didn't belong.

-- 
Eric Rostetter



From madlists at teaparty.net  Tue Mar 29 18:52:27 2005
From: madlists at teaparty.net (Tom Yates)
Date: Tue, 29 Mar 2005 19:52:27 +0100 (BST)
Subject: mysql-server
In-Reply-To: <1112121317.6f5f563401a6d@mail.ph.utexas.edu>
References: <006301c53482$52d63510$7202a8c0@ccb2vpjza>
	<1112117028.13b0c59e3f800@mail.ph.utexas.edu>
	<Pine.LNX.4.61.0503291826140.24265@risby.gatekeeper.ltd.uk>
	<1112121317.6f5f563401a6d@mail.ph.utexas.edu>
Message-ID: <Pine.LNX.4.61.0503291944190.24265@risby.gatekeeper.ltd.uk>

On Tue, 29 Mar 2005, Eric Rostetter wrote:

> Code to yum would only be of benefit if it only applied to automatic 
> runs (otherwise it would interfer with those wishing to install updates 
> or test updates on the "restricted" days).  I don't think that would be 
> practical in any case.

i'm sorry i wasn't clearer; i find the idea of hacking to yum to observe 
holidays to be a foolish one, and i'm not advocating it.  i should know by 
now that sarcasm doesn't work well in email.


-- 

   Tom Yates
   Cambridge, UK.



From rostetter at mail.utexas.edu  Tue Mar 29 19:05:51 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue, 29 Mar 2005 13:05:51 -0600
Subject: mysql-server
In-Reply-To: <007601c53487$83b9d330$7202a8c0@ccb2vpjza>
References: <007601c53487$83b9d330$7202a8c0@ccb2vpjza>
Message-ID: <1112123151.9d8e793384973@mail.ph.utexas.edu>

Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:

> Since there is no way to cache the downloads for implienting manually I
> guess I'm SOL.

No automatted way.  This is a feature missing in yum...

> I don't want to go to each and every machine (I have more than 1) and
> manually run yum to update them.

Do you run mysql on all of them?  If not, then maybe you should exclude
mysql from updates on the servers where you need it running, and update
those by hand.  But allow all other updates on the other machines. Or
some similar method of controlling updates of critical software on 
critical machines.

> It defeats the purpose of having cron.

No.  Yum and cron have nothing in common.  In fact, I would run yum in
cron in with check-update so it mails you a list of updates, so you know
that you need to update those packages on those machines.  So it in no
way "defeats the purpose of having cron."

> In fact Fedora Legacy's own documentation has a specific step for adding
> automatic updates (step 4 - 7.3 documentation).

Under the header "Decide if you want automatic updates" which implies
you must think about this first before doing it!  There is a reason
it is disabled by default!

> There is no mention that
> this process is NOT recommended by FL nor would I expect one.

We do not recommend it, nor do we say you shouldn't.  We say you should
decide if you want them, and if so, here is how to do it.

"Best Practices" dictate that you simply don't do automatic updates on
a production machine (whether linux, windows, solaris, or other).  This
has nothing to do with FL per se.

> To limit
> people to manually acting on updates devalues FL's service below
> Microsoft.

No, it differs in no way from Microsofts updates.  Microsoft also states
that you should not apply automatic updates to production/critical servers.
 
> As I seem to be a minority I will shut up now. Still I appriciate the
> work put into the updates.

You should not shut up, you should ask for better solutions to your problems.
Maybe yum could be modified to allow you to download the updates to the
cache without installing them (I think apt allows this, though I'm not sure).
Maybe you simply need to create a policy that works for you (exclude
critical-to-you services/features from auto-update, while allowing others
to have auto-update), or choosing some machines for auto-update while
making others be a manual update process.

> Paul Pettit
> 
> p.s. fedoralegacy.org is refusing connections. :(

I'm able to see it.  Anyone else seeing problems?  Can you traceroute it,
or dnslookup it to see if we can find a problem?

-- 
Eric Rostetter



From madlists at teaparty.net  Tue Mar 29 19:22:00 2005
From: madlists at teaparty.net (Tom Yates)
Date: Tue, 29 Mar 2005 20:22:00 +0100 (BST)
Subject: mysql-server
In-Reply-To: <007601c53487$83b9d330$7202a8c0@ccb2vpjza>
References: <007601c53487$83b9d330$7202a8c0@ccb2vpjza>
Message-ID: <Pine.LNX.4.61.0503291959230.24265@risby.gatekeeper.ltd.uk>

On Tue, 29 Mar 2005, Pettit, Paul wrote:

> I was using the term "federal" in it's broadest terms. Guess I should
> have used the word "government" instead ... or would you have taken
> offence to that too?

it's not an issue of "taking offence".  language is for communication, and 
the word "federal" carries some very specific meanings - which vary widely 
from one federated entity to another!  if you want a broad-brush term, how 
about simply "holidays"?

> Please try and not start some kind of 'them vs us' fight where there was
> none intended.

i'm pleased to know none such was intended; i apologise for giving the 
impression i had taken up cudgels.

> And how I handle it is obviously not too important here.

not so!  but there are definitely "wrong" ways to apply patches, and if 
you're pointing out a problem that the community believes was caused by 
the way you apply patches, they might well question your patching 
methodology before changing things to accommodate it.

but it's always worth raising things, in case you're the tip of the 
iceberg, and 5,000 other users suffer from the same problem.

> Since there is no way to cache the downloads for implienting manually I
> guess I'm SOL.

i'm sorry, but i think you're wrong, although i don't quite understand the 
comment.  i think there are probably a number of ways to do what you want 
to do, if i guess aright.  yum may or may not be the right tool to do it.

could you clarify what you're aiming at?  possibly off-list?

> I don't want to go to each and every machine (I have more than 1) and
> manually run yum to update them. It defeats the purpose of having cron.

ok.  then you might want to consider having your own release repository, 
to which you don't release patches until they satisfy your additional 
release criteria.

> p.s. fedoralegacy.org is refusing connections. :(

i use mirrordir to keep my own local cache updated, if that suggestion's 
any help.


-- 

   Tom Yates
   Cambridge, UK.



From dom at earth.li  Tue Mar 29 19:33:50 2005
From: dom at earth.li (Dominic Hargreaves)
Date: Tue, 29 Mar 2005 20:33:50 +0100
Subject: state of bugzilla (and, current kernel root exploits....)
In-Reply-To: <20050329144737.GA17121@jadzia.bu.edu>
References: <20050329144737.GA17121@jadzia.bu.edu>
Message-ID: <20050329193350.GK29340@urchin.earth.li>

On Tue, Mar 29, 2005 at 09:47:37AM -0500, Matthew Miller wrote:
> I'm trying to track the issues from Fedora alert FEDORA-2005-262,
> particularly CAN-2005-0750, which is a local root exploit. But I'm confused.
> What's the state of bugzilla for FL issues right now?

I don't know what the hold-up is, but it seems that the import hasn't
occurred yet. However there are no open kernel bugs that I can spot in
bugzilla.fedora.us, so feel free to open new legacy bugs on
bugzilla.redhat.com. The product is there and ready to go AFAIK.

Cheers,

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



From bedouglas at earthlink.net  Tue Mar 29 19:13:21 2005
From: bedouglas at earthlink.net (bruce)
Date: Tue, 29 Mar 2005 11:13:21 -0800
Subject: dependency question doing install...
Message-ID: <02bf01c53493$60e5d8c0$0301a8c0@Mesa.com>

hi...

i do an install, and get the following...

[root at lserver2 rpm]# rpm - Uvh openssl-0.9.7e-3.i386.rpm
/etc/security/selinux/file_contexts: No such file or directory
warning: openssl-0.9.7e-3.i386.rpm: V3 DSA signature: NOKEY, key ID 30c9ecf8
error: Failed dependencies:
        libk5crypto.so.3(k5crypto_3_MIT) is needed by openssl-0.9.7e-3

i'm not sure why it's complaining about lib .so.3 as the file is in the
/usr/lib dir...
./usr/lib/libk5crypto.so.3   <<<<<<<<<<<<<<<<<<<<
./usr/lib/libk5crypto.so.3.0
./usr/lib/libk5crypto.a
./usr/lib/libk5crypto.so

is rpm expecting the libk5crypto file to be in another dir???

any idea as to what's going on, and how to correct it?

thanks

bruce




From michal at harddata.com  Tue Mar 29 20:00:50 2005
From: michal at harddata.com (Michal Jaegermann)
Date: Tue, 29 Mar 2005 13:00:50 -0700
Subject: mysql-server
In-Reply-To: <1112123151.9d8e793384973@mail.ph.utexas.edu>;
	from rostetter@mail.utexas.edu on Tue, Mar 29, 2005 at 01:05:51PM
	-0600
References: <007601c53487$83b9d330$7202a8c0@ccb2vpjza>
	<1112123151.9d8e793384973@mail.ph.utexas.edu>
Message-ID: <20050329130050.A3532@mail.harddata.com>

On Tue, Mar 29, 2005 at 01:05:51PM -0600, Eric Rostetter wrote:
> Maybe yum could be modified to allow you to download the updates to the
> cache without installing them

Not much need for this, really.  'yum check-update' will produce not
only a status but a list of packages if any available.  Feeding that
to a program (lftp, wget, .... ) which will retrieve those from
suitable mirrors is not that complicated.

   Michal



From sheltren at cs.ucsb.edu  Tue Mar 29 20:28:03 2005
From: sheltren at cs.ucsb.edu (Jeff Sheltren)
Date: Tue, 29 Mar 2005 12:28:03 -0800
Subject: using yum to upgrade/install an FC2-> FC3 app
In-Reply-To: <025901c53486$964fa070$0301a8c0@Mesa.com>
Message-ID: <BE6EFA53.21A43%sheltren@cs.ucsb.edu>

On 3/29/05 9:41 AM, "bruce" <bedouglas at earthlink.net> wrote:

> hi...
> 
> i have mysql (FC2) on an FC2 machine. I'd like to install/upgrade to mysql
> (FC3). however using rpm -Uvh 'blah' gives the usual dependency issues...
> 
> what's the best/correct way to upgrade/install to the FC3 mysql? would yum
> be the best approach? if i force the install, i'm concerned that i'll break
> the setup...
> 
> what's the best/correct way to do this...??
> 
> i'm trying to go from mysql (FC2) --> mysql (FC3)
> 
> thanks
> 
> bruce

Since I get the impression you want to upgrade *only* mysql, why not grab
the RPM(s) from mysql.com?  They should work fine on fc2.

-Jeff




From ismanager at ccbnpts.com  Tue Mar 29 20:30:44 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Tue, 29 Mar 2005 14:30:44 -0600
Subject: mysql-server
In-Reply-To: <1112123151.9d8e793384973@mail.ph.utexas.edu>
Message-ID: <009501c5349e$2eaf6190$7202a8c0@ccb2vpjza>

> From: Eric Rostetter 
> 
> Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:
> 
> > Since there is no way to cache the downloads for 
> implienting manually I
> > guess I'm SOL.
> 
> No automatted way.  This is a feature missing in yum...
> 
> > I don't want to go to each and every machine (I have more 
> than 1) and
> > manually run yum to update them.
> 
> Do you run mysql on all of them?  If not, then maybe you 
> should exclude
> mysql from updates on the servers where you need it running, 
> and update
> those by hand.  But allow all other updates on the other machines. Or
> some similar method of controlling updates of critical software on 
> critical machines.
> 

On the ones I update using yum yes, they all have mysqld service running
for local DB hosting duties. I've added mySQL (mysql*) to the excludes
list as of Monday.

> > It defeats the purpose of having cron.
> 
> No.  Yum and cron have nothing in common.  In fact, I would run yum in
> cron in with check-update so it mails you a list of updates, 
> so you know
> that you need to update those packages on those machines.  So it in no
> way "defeats the purpose of having cron."
> 

This is in referance to having yum.cron by default listed in cron.daily.
Yes, I know that they are not related except in that cron governs when
yum updates if the yum daemon is running (via 'service' and
'chkconfig'). 

Running yum as 'check-update' requires editing the yum.cron script or by
rolling your own. I'm not adverse to doing that (done it enough) but
it's not much better than going to each machine in turn and running 'yum
update' individually. It is an option I'll grant you.

> > In fact Fedora Legacy's own documentation has a specific 
> step for adding
> > automatic updates (step 4 - 7.3 documentation).
> 
> Under the header "Decide if you want automatic updates" which implies
> you must think about this first before doing it!  There is a reason
> it is disabled by default!
> 

Disabled by default means nothing when it comes to wanting to automate
update downloads. People will turn it on as soon as they reach Step 4 in
the documentation. We all want timely updates and don't want to sit and
watch a program run (unless we are worried it will bomb) for this
purpose. 

> > There is no mention that
> > this process is NOT recommended by FL nor would I expect one.
> 
> We do not recommend it, nor do we say you shouldn't.  We say 
> you should
> decide if you want them, and if so, here is how to do it.
> 
> "Best Practices" dictate that you simply don't do automatic updates on
> a production machine (whether linux, windows, solaris, or 
> other).  This
> has nothing to do with FL per se.
> 

Most would say that being able to download overnight or automatically
any update that came out, that has passed through QA, and has been maked
as "critical", in a timely manner is a "best practice". In fact if you
have a sever that is in danger of being compromised unless said update
is done it's not just a "best practice" it's a requirement for continued
employment.

If QA is not robust enough to trust these updates on production servers
(and just how many people here are still "playing" with 7.3 or 9?) then
I think there is an underlying problem.

> > To limit
> > people to manually acting on updates devalues FL's service below
> > Microsoft.
> 
> No, it differs in no way from Microsofts updates.  Microsoft 
> also states
> that you should not apply automatic updates to 
> production/critical servers.
>  

Incorrect!

All critical updates that M$ puts out are REQUIRED for production
servers, it's not an option even though many admins think it is (and
thus look at the number of hacked systems). The patches they put out
have passed QA and are certified to fix the related issue.

The same is true for RHEL, the updates they put out are good for prime
time. It would be worthless to have updates if you first had to try them
out on a test server just to see if the server will run. 

If your stand is that all updates need to be further tested when you
download them from FL thats just ... eh?

Well yeah maybe if they relate to other apps (or other apps rely on
them) but where does that figure into the mySQL crash after update?
Simply put it doesn't, the package updated fine, didn't break anything,
and failed to reboot on it's own. This happened on a holiday thus
compounding the problem for a (unlucky) few. It's not biterness but
concern for future updates and the haphazard way they are being put out.
But if I'm the only one worried then ... meh. I'll live and I'm sure the
world won't end if this is pushed aside.

> > As I seem to be a minority I will shut up now. Still I 
> appriciate the
> > work put into the updates.
> 
> You should not shut up, you should ask for better solutions 
> to your problems.
> Maybe yum could be modified to allow you to download the 
> updates to the
> cache without installing them (I think apt allows this, 
> though I'm not sure).
> Maybe you simply need to create a policy that works for you (exclude
> critical-to-you services/features from auto-update, while 
> allowing others
> to have auto-update), or choosing some machines for auto-update while
> making others be a manual update process.
> 

My point (which has been lost and was an opinion btw) was that to help
the end users from getting bit by a major package update going south
that updates be distrubuted in a timely manner but taking into
consideration that some days of the month are bad days. Since most here
are euro or american it's not that hard to figure out the big ones.

Tom actually had a good idea (sarcastic though it was) in that more
control of yum is needed. To that I say "duh!" now that I see that yum
works too black/white for most admin's (at least me) needs. Since I'm a
programmer I'll deal with the random timing of updates that FL puts out
by controling when yum really updates, not just every freaking day like
they have it set at.

But again I reiterate, releasing updates on certain days is ***IMHO*** a
bad idea because not all are willing / able to fix yum on their own to
ensure that they aren't on holiday when the next big package downloads
then pukes (manually updating not included).

Take MHO for what it's worth or whatever little you *think* it's worth. 

> > Paul Pettit
> > 
> > p.s. fedoralegacy.org is refusing connections. :(
> 
> I'm able to see it.  Anyone else seeing problems?  Can you 
> traceroute it,
> or dnslookup it to see if we can find a problem?
> 
> -- 
> Eric Rostetter
> 

It was the web site and it's back up now.

Peace.

Paul Pettit



From bedouglas at earthlink.net  Tue Mar 29 20:38:20 2005
From: bedouglas at earthlink.net (bruce)
Date: Tue, 29 Mar 2005 12:38:20 -0800
Subject: using yum to upgrade/install an FC2-> FC3 app
In-Reply-To: <BE6EFA53.21A43%sheltren@cs.ucsb.edu>
Message-ID: <030501c5349f$3f435970$0301a8c0@Mesa.com>



-----Original Message-----
From: fedora-legacy-list-bounces at redhat.com
[mailto:fedora-legacy-list-bounces at redhat.com]On Behalf Of Jeff Sheltren
Sent: Tuesday, March 29, 2005 12:28 PM
To: bedouglas at earthlink.net, Discussion of the Fedora Legacy Project
Subject: Re: using yum to upgrade/install an FC2-> FC3 app


On 3/29/05 9:41 AM, "bruce" <bedouglas at earthlink.net> wrote:

> hi...
>
> i have mysql (FC2) on an FC2 machine. I'd like to install/upgrade to mysql
> (FC3). however using rpm -Uvh 'blah' gives the usual dependency issues...
>
> what's the best/correct way to upgrade/install to the FC3 mysql? would yum
> be the best approach? if i force the install, i'm concerned that i'll
break
> the setup...
>
> what's the best/correct way to do this...??
>
> i'm trying to go from mysql (FC2) --> mysql (FC3)
>
> thanks
>
> bruce

Since I get the impression you want to upgrade *only* mysql, why not grab
the RPM(s) from mysql.com?  They should work fine on fc2.

-Jeff

---------------------------------
your suggestion to grab the rpms from mysql is exactly what i've been trying
to do... and then it gave me dependency issues. which is where i am now.

it now appears that i've screwed things up...

i have:
[root at lserver2 rpm]# mysql -u root -p
mysql: /lib/libk5crypto.so.3: no version information available (required by
/lib/libssl.so.5)
mysql: /usr/lib/libkrb5.so.3: no version information available (required by
/lib/libssl.so.5)
mysql: error while loading shared libraries: mysql: undefined symbol:
get_defaults_files

which tells me that i have something weird going on...

searching google/etc.. doesn't tell me what 'no version information
available' means, so i'm at a loss as to where to look for a solution...

thanks...

bruce



--
fedora-legacy-list mailing list
fedora-legacy-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-legacy-list



From cave.dnb at tiscali.fr  Tue Mar 29 20:39:14 2005
From: cave.dnb at tiscali.fr (nigel henry)
Date: Tue, 29 Mar 2005 21:39:14 +0100
Subject: dependeny issues.... upgrading apps
In-Reply-To: <027901c5348c$59194020$0301a8c0@Mesa.com>
References: <027901c5348c$59194020$0301a8c0@Mesa.com>
Message-ID: <200503292139.14047.cave.dnb@tiscali.fr>

Hi Bruce. You'd probably be better off on the Redhat Fedora forum or mailing 
list as Fedora Legacy is dealing with FC1 and earlier. All the same, 
personally I don't think you're going to have much success with this one. 
I've put a RH9 app on FC1 and its worked. A RH8 one on FC2! Well you dont 
want to know about that. I think the problem is going to be that the FC3 
kernel has been presented to the app developers, and they've taken advantage 
of it's advanced capabilities, therefore in your case you've got mysql 
offered to you with advanced capabilities. Putting the dependencies to one 
side, whether the FC3 version of mysql is going to play with the FC2 kernel 
is a bit hit and miss. Bringing the dependencies into the scenario you could 
find yourself in some sort of dependency chain reaction, with more and more 
dependencies needing to be satisfied. If you desperately need the added 
funtionality of mysql as provided with FC3, your best bet in my honest 
opinion is to upgrade the OS to FC3. I know there are some issues with FC3 
with music software apps, as I participate in the planetccrma list. But 
probably most of the run of the mill stuff works perfectly well. Let me know 
which way you decide to go. Nigel. 





On Tuesday 29 Mar 2005 7:23 pm, bruce wrote:
> hi...
>
> i'm looking to install/upgrade mysql (FC2->FC3) on a FC2 system. (i need
> the additional functionality and thought i'd try to use the rpms that were
> created for FC3.)
>
> my question concerns the dependency issues that i get when i try to install
> thngs like the kerebos libs. if i write over these libs with an updated
> version, will other apps complain??
>
> how can i go about doing an upgrade of an app, without having to upgrade
> the entire OS??
>
> thanks
>
> bruce
>
>
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list



From ismanager at ccbnpts.com  Tue Mar 29 20:41:01 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Tue, 29 Mar 2005 14:41:01 -0600
Subject: mysql-server
In-Reply-To: <Pine.LNX.4.61.0503291959230.24265@risby.gatekeeper.ltd.uk>
Message-ID: <009601c5349f$9e8ea4c0$7202a8c0@ccb2vpjza>

> From: Tom Yates [mailto:madlists at teaparty.net] 
> 
> On Tue, 29 Mar 2005, Pettit, Paul wrote:
> 
> > I was using the term "federal" in it's broadest terms. 
> Guess I should
> > have used the word "government" instead ... or would you have taken
> > offence to that too?
> 
> it's not an issue of "taking offence".  language is for 
> communication, and 
> the word "federal" carries some very specific meanings - 
> which vary widely 
> from one federated entity to another!  if you want a 
> broad-brush term, how 
> about simply "holidays"?
> 
> > Please try and not start some kind of 'them vs us' fight 
> where there was
> > none intended.
> 
> i'm pleased to know none such was intended; i apologise for 
> giving the 
> impression i had taken up cudgels.
> 

Np.

The word "holidays" is too broad and it too is open to translation. My
focus was on holidays that are the typical ones that businesses close
on. These are usually major religious or government holidays. There are
tons more that are not truly recognized in all countries or even in the
countries they originated from.

> > And how I handle it is obviously not too important here.
> 
> not so!  but there are definitely "wrong" ways to apply 
> patches, and if 
> you're pointing out a problem that the community believes was 
> caused by 
> the way you apply patches, they might well question your patching 
> methodology before changing things to accommodate it.
> 
> but it's always worth raising things, in case you're the tip of the 
> iceberg, and 5,000 other users suffer from the same problem.
> 

I have no idea if it is or isn't, I was mearly stating my opinion that I
thought more care should be taken for those that just *might* be relying
on autoupdates more than say you are.

Of course you can't please everyone, just find the best compromise as
you can.

> > Since there is no way to cache the downloads for 
> implienting manually I
> > guess I'm SOL.
> 
> i'm sorry, but i think you're wrong, although i don't quite 
> understand the 
> comment.  i think there are probably a number of ways to do 
> what you want 
> to do, if i guess aright.  yum may or may not be the right 
> tool to do it.
> 
> could you clarify what you're aiming at?  possibly off-list?
> 

Hopefully I've covered this in my previous response but certainly if I'm
still not being clear I'll email you directly. I prefer that the list
get a chance to sound off but ...

> > I don't want to go to each and every machine (I have more 
> than 1) and
> > manually run yum to update them. It defeats the purpose of 
> having cron.
> 
> ok.  then you might want to consider having your own release 
> repository, 
> to which you don't release patches until they satisfy your additional 
> release criteria.
> 

My goal is not just for me. Yeah sure it will affect me but I'm sure
others had mySQL failures that never posted anything. The crux of the
thread is to ensure that maybe it won't happen again at such and bad
time as when people are out on holiday.

As for me I know what I'm going to do from here out. No need to setup a
repository or other massive changes, simply write a better script for
the cron to deal with (you gave me the idea btw).

> > p.s. fedoralegacy.org is refusing connections. :(
> 
> i use mirrordir to keep my own local cache updated, if that 
> suggestion's 
> any help.
> 
> 
> -- 
> 
>    Tom Yates
>    Cambridge, UK.
> 

It was the web site and it's back up now.

Paul Pettit



From ismanager at ccbnpts.com  Tue Mar 29 20:49:35 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Tue, 29 Mar 2005 14:49:35 -0600
Subject: mysql-server
In-Reply-To: <20050329130050.A3532@mail.harddata.com>
Message-ID: <009701c534a0$d13db0e0$7202a8c0@ccb2vpjza>

> Michal Jaegermann
> 
> On Tue, Mar 29, 2005 at 01:05:51PM -0600, Eric Rostetter wrote:
> > Maybe yum could be modified to allow you to download the 
> updates to the
> > cache without installing them
> 
> Not much need for this, really.  'yum check-update' will produce not
> only a status but a list of packages if any available.  Feeding that
> to a program (lftp, wget, .... ) which will retrieve those from
> suitable mirrors is not that complicated.
> 
>    Michal
> 

Hmmm, covered this, but again that is a manual fix. The problem is when
you want to do updates automaticaly but in doing so updates come out at
times when there is no support ready (on holiday/vacation/etc) for
undocumented problems.

Piping 'yum check-update' through another tool to download is
interesting but it still causes you to have to go to each server and
update manually. Plus I'm not certain that 'check-update' checks for
dependancies which if it doesn't would cause to extra work to fill those
before doing the update and thus increasing the administration overhead
on each server per update. Anyone know if 'check-update' checks for
dependancies as well as updates?

Paul Pettit



From ame1 at extratech.com  Tue Mar 29 21:22:25 2005
From: ame1 at extratech.com (Alan M. Evans)
Date: Tue, 29 Mar 2005 13:22:25 -0800
Subject: mysql-server
In-Reply-To: <009701c534a0$d13db0e0$7202a8c0@ccb2vpjza>
References: <009701c534a0$d13db0e0$7202a8c0@ccb2vpjza>
Message-ID: <1112131345.13577.19.camel@zosma.extratech.com>

On Tue, 2005-03-29 at 12:49, Pettit, Paul wrote:
> Hmmm, covered this, but again that is a manual fix. The problem is when
> you want to do updates automaticaly but in doing so updates come out at
> times when there is no support ready (on holiday/vacation/etc) for
> undocumented problems.

Why is nobody suggesting the obvious solution?

If you don't want automatic updates during certain periods, just disable
auto-updating before said period, and re-enable after. This way, nobody
maintaining packages needs to worry about what may or may not be a
holiday for any particular client.

Surely this can be easily scripted so all auto-updating machines cease
updating for the intended period (weekend, holiday, vacation, etc.)
Worst case: admin needs to run a "stop-updating" script before leaving,
and executes a "resume-updating" script when returning.

-- 
Alan M. Evans <ame1 at extratech.com>



From michal at harddata.com  Tue Mar 29 21:47:12 2005
From: michal at harddata.com (Michal Jaegermann)
Date: Tue, 29 Mar 2005 14:47:12 -0700
Subject: mysql-server
In-Reply-To: <009701c534a0$d13db0e0$7202a8c0@ccb2vpjza>;
	from ismanager@ccbnpts.com on Tue, Mar 29, 2005 at 02:49:35PM
	-0600
References: <20050329130050.A3532@mail.harddata.com>
	<009701c534a0$d13db0e0$7202a8c0@ccb2vpjza>
Message-ID: <20050329144712.A5987@mail.harddata.com>

On Tue, Mar 29, 2005 at 02:49:35PM -0600, Pettit, Paul wrote:
> > Michal Jaegermann
> > 
> > On Tue, Mar 29, 2005 at 01:05:51PM -0600, Eric Rostetter wrote:
> > > Maybe yum could be modified to allow you to download the 
> > updates to the
> > > cache without installing them
> > 
> > Not much need for this, really.  'yum check-update' will produce not
> > only a status but a list of packages if any available.  Feeding that
> > to a program (lftp, wget, .... ) which will retrieve those from
> > suitable mirrors is not that complicated.
> 
> Hmmm, covered this, but again that is a manual fix.

What is "manual"?  Wrting a script or applying updates you
automatically retrieved?

> The problem is when
> you want to do updates automaticaly but in doing so updates come out at
> times when there is no support ready (on holiday/vacation/etc) for
> undocumented problems.

'man 5 crontab'.  You may actually specify in which days you want
cron to trigger the given action.  Another option is for your update
script to check a list of "banned" dates and simply exit if the 
current day happens to be on that list.  Clearly you can combine
both approaches if desired.

You should not expect that a general distribution will set up such
detailed administrative policies for you but this is something you
can easily do yourself.

   Michal



From drees at greenhydrant.com  Tue Mar 29 22:14:16 2005
From: drees at greenhydrant.com (David Rees)
Date: Tue, 29 Mar 2005 14:14:16 -0800 (PST)
Subject: mysql-server
In-Reply-To: <007601c53487$83b9d330$7202a8c0@ccb2vpjza>
References: <Pine.LNX.4.61.0503291826140.24265@risby.gatekeeper.ltd.uk>
	<007601c53487$83b9d330$7202a8c0@ccb2vpjza>
Message-ID: <1447.208.48.139.172.1112134456.squirrel@www.greenhydrant.com>

On Tue, March 29, 2005 9:48 am, Pettit, Paul said:
>
> I don't want to go to each and every machine (I have more than 1) and
> manually run yum to update them. It defeats the purpose of having cron.
> In fact Fedora Legacy's own documentation has a specific step for adding
> automatic updates (step 4 - 7.3 documentation). There is no mention that
> this process is NOT recommended by FL nor would I expect one. To limit
> people to manually acting on updates devalues FL's service below
> Microsoft.

I use a modified /etc/cron.daily/yum.cron to email me when a machine has
updates to apply.  I'll paste it in below.

To handle an automatic update for all machines, you could write a script
which goes out and runs yum update on all machines using ssh and public
key authentication so no manual intervention is required except to
initiate the command.  For example for the automatic update script:

#!/bin/sh
MACHLIST="mach1 mach2 mach3"
for i in $MACHLIST; do
	ssh root@$i yum -y update
done

You may want to use sudo instead of logging in directly as root.

For the daily script which tells me daily which machines need updating:

#!/bin/sh

if [ -f /var/lock/subsys/yum ]; then
	YUM="/usr/bin/yum"
	DEBUG="-e 0 -d 0"
	EMAIL="drees at greenhydrant.com"
	LOG=`mktemp -q /tmp/yum.XXXXXX`
	if [ $? -ne 0 ]; then
    	echo "$0: Can't create temp file for yum update, exiting..."
    	exit 1
	fi
	$YUM -R 120 $DEBUG list updates | grep -v \
		"No Packages Available to List" >> ${LOG}
	# Uncomment the next line to automatically update packages
	#$YUM -R 120 $DEBUG -y update >> ${LOG}
	if [ -s ${LOG} ] ; then
		cat ${LOG} | mail -s "Yum Update Alert `hostname`" ${EMAIL}
	else
		# No packages to update, clean the cache
		$YUM $DEBUG clean all
	fi

	rm -f ${LOG}
fi

Hope this helps.  Feel free to use these scripts as needed or post them on
the FAQ as necessary!

-Dave



From ismanager at ccbnpts.com  Tue Mar 29 22:16:10 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Tue, 29 Mar 2005 16:16:10 -0600
Subject: mysql-server
In-Reply-To: <20050329144712.A5987@mail.harddata.com>
Message-ID: <001101c534ac$e9b6d5a0$7202a8c0@ccb2vpjza>

> Michal Jaegermann
> 
> On Tue, Mar 29, 2005 at 02:49:35PM -0600, Pettit, Paul wrote:
> > > Michal Jaegermann
> > > 
> > > On Tue, Mar 29, 2005 at 01:05:51PM -0600, Eric Rostetter wrote:
> > > > Maybe yum could be modified to allow you to download the 
> > > updates to the
> > > > cache without installing them
> > > 
> > > Not much need for this, really.  'yum check-update' will 
> produce not
> > > only a status but a list of packages if any available.  
> Feeding that
> > > to a program (lftp, wget, .... ) which will retrieve those from
> > > suitable mirrors is not that complicated.
> > 
> > Hmmm, covered this, but again that is a manual fix.
> 
> What is "manual"?  Wrting a script or applying updates you
> automatically retrieved?
> 

Applying the updates.

The overhead (work hours) is high if said downloads are on multiple
servers and updates must be run on each (as well as dependancy
checking). My dad always said "work smarter". 

I'm already writing a script to deal with the issue. Hopefully this will
be a better fit than the stock yum setup.

> > The problem is when
> > you want to do updates automaticaly but in doing so updates 
> come out at
> > times when there is no support ready (on holiday/vacation/etc) for
> > undocumented problems.
> 
> 'man 5 crontab'.  You may actually specify in which days you want
> cron to trigger the given action.  Another option is for your update
> script to check a list of "banned" dates and simply exit if the 
> current day happens to be on that list.  Clearly you can combine
> both approaches if desired.
> 

Pretty much what I'm setting up.

I guess I'm just trying to look at the bigger picture where not all can
do what the rest of us can or at the same skill level.

> You should not expect that a general distribution will set up such
> detailed administrative policies for you but this is something you
> can easily do yourself.
> 
>    Michal

I never said I did, where did you get that?

The problem is that as setup (via FL's own documentation) there is no
granular control. The default is 'on' or 'off' and that's it. Not very
handy when you add to that FL's policy of pushing updates out as soon as
possible without consideration to timing. It's not a bad policy but ...

It's sort of just one of those times when multiple normally unrelated
occurances happen at the same time (i.e. mysql update, holiday, broken
restart function in said update). Many ways to fix it but I think one
way to help would be to maybe schedule pending updates. That might be a
problem but hey, this is a discussion right? 

Paul Pettit



From ad+lists at uni-x.org  Tue Mar 29 22:19:37 2005
From: ad+lists at uni-x.org (Alexander Dalloz)
Date: Wed, 30 Mar 2005 00:19:37 +0200
Subject: dependency question doing install...
In-Reply-To: <02bf01c53493$60e5d8c0$0301a8c0@Mesa.com>
References: <02bf01c53493$60e5d8c0$0301a8c0@Mesa.com>
Message-ID: <1112134777.11539.508.camel@serendipity.dogma.lan>

Am Di, den 29.03.2005 schrieb bruce um 21:13:

> i do an install, and get the following...

As Nigel already said: your update trials are off topic here on the
list. Neither FC2 nor FC3 are handed over to the Fedora Legacy Project.

> [root at lserver2 rpm]# rpm - Uvh openssl-0.9.7e-3.i386.rpm
> /etc/security/selinux/file_contexts: No such file or directory
> warning: openssl-0.9.7e-3.i386.rpm: V3 DSA signature: NOKEY, key ID 30c9ecf8
> error: Failed dependencies:
>         libk5crypto.so.3(k5crypto_3_MIT) is needed by openssl-0.9.7e-3

> bruce

That is no FC2 OpenSSL RPM - so what do you expect? You are on the best
way to destroy your system.

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773
legal statement: http://www.uni-x.org/legal.html
Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.10-1.770_FC2smp 
Serendipity 00:15:48 up 12 days, 21:12, load average: 0.62, 0.75, 0.63 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050330/61501f80/attachment.sig>

From gregg at cytetech.com  Tue Mar 29 21:11:27 2005
From: gregg at cytetech.com (Gregg Wonderly)
Date: Tue, 29 Mar 2005 15:11:27 -0600
Subject: automatic updates
In-Reply-To: <20050329203425.4E622738C7@hormel.redhat.com>
References: <20050329203425.4E622738C7@hormel.redhat.com>
Message-ID: <4249C47F.3060202@cytetech.com>

fedora-legacy-list-request at redhat.com wrote:

>>One thing I'd like to point out. Considering that many (all?) of us are
>>using the Fedora Legacy updates in an automatic mode, care should be
> 
> 
> No, please don't use automatic updates on a production server.  It is
> fine if you want to do it on a desktop machine or something, but don't
> do this on a production server or important machine!

What's the point of hurrying out the door if noone can install it till 
monday because automated updates shouldn't be used?

Gregg Wonderly



From marcdeslauriers at videotron.ca  Tue Mar 29 22:56:03 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Tue, 29 Mar 2005 17:56:03 -0500
Subject: mysql-server
In-Reply-To: <009501c5349e$2eaf6190$7202a8c0@ccb2vpjza>
References: <009501c5349e$2eaf6190$7202a8c0@ccb2vpjza>
Message-ID: <1112136963.7994.13.camel@mdlinux>

On Tue, 2005-03-29 at 14:30 -0600, Pettit, Paul wrote:
> Well yeah maybe if they relate to other apps (or other apps rely on
> them) but where does that figure into the mySQL crash after update?
> Simply put it doesn't, the package updated fine, didn't break anything,
> and failed to reboot on it's own. This happened on a holiday thus
> compounding the problem for a (unlucky) few. It's not biterness but
> concern for future updates and the haphazard way they are being put out.
> But if I'm the only one worried then ... meh. I'll live and I'm sure the
> world won't end if this is pushed aside.

Although I'm sorry it happened to you on a weekend, I don't think we'll
be changing our release schedule. We actually released the mysql update
on a Thursday.

I do consider mysql not restarting itself a bug though. Could you (or
somebody else on this list) please enter it in bugzilla at
bugzilla.redhat.com under Fedora Legacy. There are more mysql updates
coming up soon and I would like to fix the restart issue before they
come out as I personally think automatic yum updates should work
properly.

Thanks,

Marc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050329/0962afef/attachment.sig>

From rostetter at mail.utexas.edu  Tue Mar 29 23:00:29 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue, 29 Mar 2005 17:00:29 -0600
Subject: mysql-server
In-Reply-To: <20050329130050.A3532@mail.harddata.com>
References: <007601c53487$83b9d330$7202a8c0@ccb2vpjza>
	<1112123151.9d8e793384973@mail.ph.utexas.edu>
	<20050329130050.A3532@mail.harddata.com>
Message-ID: <1112137229.a7709be4060bc@mail.ph.utexas.edu>

Quoting Michal Jaegermann <michal at harddata.com>:

> On Tue, Mar 29, 2005 at 01:05:51PM -0600, Eric Rostetter wrote:
> > Maybe yum could be modified to allow you to download the updates to the
> > cache without installing them
> 
> Not much need for this, really.  'yum check-update' will produce not
> only a status but a list of packages if any available.  Feeding that
> to a program (lftp, wget, .... ) which will retrieve those from
> suitable mirrors is not that complicated.
> 
>    Michal

I think that it *is* that complicated for someone who is at only a basic
admin/programmer level.  And why should everyone have to implement their
own version of this, when it could be added to yum?

-- 
Eric Rostetter



From ismanager at ccbnpts.com  Tue Mar 29 23:12:02 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Tue, 29 Mar 2005 17:12:02 -0600
Subject: mysql-server
In-Reply-To: <1112136963.7994.13.camel@mdlinux>
Message-ID: <002801c534b4$b7c36240$7202a8c0@ccb2vpjza>

> Marc Deslauriers
> 
> On Tue, 2005-03-29 at 14:30 -0600, Pettit, Paul wrote:
> > Well yeah maybe if they relate to other apps (or other apps rely on
> > them) but where does that figure into the mySQL crash after update?
> > Simply put it doesn't, the package updated fine, didn't 
> break anything,
> > and failed to reboot on it's own. This happened on a holiday thus
> > compounding the problem for a (unlucky) few. It's not biterness but
> > concern for future updates and the haphazard way they are 
> being put out.
> > But if I'm the only one worried then ... meh. I'll live and 
> I'm sure the
> > world won't end if this is pushed aside.
> 
> Although I'm sorry it happened to you on a weekend, I don't 
> think we'll
> be changing our release schedule. We actually released the 
> mysql update
> on a Thursday.
> 

Heh, well do you happen to know when the yum auto update runs? You are
aware of the impact that FL's documentation has if you simply follow
step 4 and make no other changes? It is FL's documentation after all so
you should know that those using the yum auto update would update Friday
MORNING at 4am or so (assuming that cron.daily is running per stock
settings).

As for changing your schedule ... what schedule?! Lol!

Look, all I wanted to do was point out a particular situation. If the
powers that be (i.e. you?) feel it's of no concern than so be it. Life
goes on, we find work arounds, and things proceed in a (somewhat)
orderly fasion. I hope that those "powers" take note but if not then oh
well, at least I did my part and spoke up and no one can say "why did
that update fail on Christmas!" We all know now that it's possible that
an FL update will appear on Christmas Eve and should plan and program
accordingly. :)

> I do consider mysql not restarting itself a bug though. Could you (or
> somebody else on this list) please enter it in bugzilla at
> bugzilla.redhat.com under Fedora Legacy. There are more mysql updates
> coming up soon and I would like to fix the restart issue before they
> come out as I personally think automatic yum updates should work
> properly.
> 
> Thanks,
> 
> Marc.
> 

I'll see what I can do. Not sure if I have an account there but if not
I'll make one when I get a few minutes free. Honestly though I think
othes would be better versed in the actual bug. I didn't know what
caused it till I read it here.

Peace.

Paul Pettit



From rostetter at mail.utexas.edu  Tue Mar 29 23:15:34 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue, 29 Mar 2005 17:15:34 -0600
Subject: mysql-server
In-Reply-To: <001101c534ac$e9b6d5a0$7202a8c0@ccb2vpjza>
References: <001101c534ac$e9b6d5a0$7202a8c0@ccb2vpjza>
Message-ID: <1112138134.25ff49c919f0f@mail.ph.utexas.edu>

Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:

> The overhead (work hours) is high if said downloads are on multiple
> servers and updates must be run on each (as well as dependancy
> checking). My dad always said "work smarter".

But is it "working smarter" if doing so results in your machines or
services going down?  I'd say not.

> It's sort of just one of those times when multiple normally unrelated
> occurances happen at the same time (i.e. mysql update, holiday, broken
> restart function in said update). Many ways to fix it but I think one
> way to help would be to maybe schedule pending updates. That might be a
> problem but hey, this is a discussion right?

Yes, it is a discussion.  Your solution won't work. But maybe we'll get
a solution that does work by having this discussion.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Tue Mar 29 23:18:19 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue, 29 Mar 2005 17:18:19 -0600
Subject: automatic updates
In-Reply-To: <4249C47F.3060202@cytetech.com>
References: <20050329203425.4E622738C7@hormel.redhat.com>
	<4249C47F.3060202@cytetech.com>
Message-ID: <1112138299.ede214881baaa@mail.ph.utexas.edu>

Quoting Gregg Wonderly <gregg at cytetech.com>:

> >>One thing I'd like to point out. Considering that many (all?) of us are
> >>using the Fedora Legacy updates in an automatic mode, care should be
> >
> >
> > No, please don't use automatic updates on a production server.  It is
> > fine if you want to do it on a desktop machine or something, but don't
> > do this on a production server or important machine!
> 
> What's the point of hurrying out the door if noone can install it till
> monday because automated updates shouldn't be used?

Not using automatted updates doesn't mean it can't be installed until Monday.

Maybe specific people can't/won't update until Monday, but I assure you others
do work/update on weekends and holidays.

Besides, now who is going to define the days.  My Monday is different than
Monday in Australia.  How would we reconcile the time differences between
locations?

> Gregg Wonderly

-- 
Eric Rostetter



From matt.followers at gmail.com  Tue Mar 29 20:37:14 2005
From: matt.followers at gmail.com (Matthew Nuzum)
Date: Tue, 29 Mar 2005 14:37:14 -0600
Subject: mysql-server
In-Reply-To: <20050329130050.A3532@mail.harddata.com>
Message-ID: <4249bc86.33c30268.6586.ffff8da9@mx.gmail.com>

> On Tue, Mar 29, 2005 at 01:05:51PM -0600, Eric Rostetter wrote:
> > Maybe yum could be modified to allow you to download the updates to the
> > cache without installing them
>
> Not much need for this, really.  'yum check-update' will produce not
> only a status but a list of packages if any available.  Feeding that
> to a program (lftp, wget, .... ) which will retrieve those from
> suitable mirrors is not that complicated.
>
>    Michal

Sorry for jumping in here so late, I haven't really followed the discussion
closely but I just thought I should mention this. One of the offices I set
up had a slow internet connection and getting updates to all the computers
was tricky. The caching proxy SQUID when set-up in transparent proxying mode
caused the updates to download extremely fast for each subsequent computer
that installed updates after the first computer downloaded it.

I suspect that you could just install a SQUID cache (not in transparent
proxying mode) and tell yum to use it as a proxy server, allowing you to
basically just proxy your updates.

We even found a few tricks that allowed us to cache Microsoft's Windows
updates and our antivirus software's updates (both of which send headers to
prevent caching) allowing us to drastically reduce our bandwidth
requirements.

Just some food for thought. Sorry if this was completely off-topic.

-- 
Matthew Nuzum <matt at followers.net>
www.followers.net - Makers of "Elite Content Management System"
View samples of Elite CMS in action by visiting
http://www.elitecms.com



From rostetter at mail.utexas.edu  Tue Mar 29 23:25:34 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue, 29 Mar 2005 17:25:34 -0600
Subject: mysql-server
In-Reply-To: <002801c534b4$b7c36240$7202a8c0@ccb2vpjza>
References: <002801c534b4$b7c36240$7202a8c0@ccb2vpjza>
Message-ID: <1112138734.e9c0f9e5bfbee@mail.ph.utexas.edu>

Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:

> Heh, well do you happen to know when the yum auto update runs? You are

When ever you tell it to.

> aware of the impact that FL's documentation has if you simply follow
> step 4 and make no other changes?

So why don't you propose changes to the docs?

> It is FL's documentation after all so

FL is a community.  The docs are the community's docs.  As part of the
community, they are now your docs also.  If you find fault in them,
help change them.

> you should know that those using the yum auto update would update Friday
> MORNING at 4am or so (assuming that cron.daily is running per stock
> settings).

And you implemented it, so hopefully *you* would know when it would run,
and change it if needed.

But, as your discussion (not you) pointed out, the docs probably need
updating.  It's now on my todo list because of your discussion.

> Look, all I wanted to do was point out a particular situation. If the

You also pointed out a particular solution.  It was rejected.  But some
people would still like to help you and others to find another solution.
If you don't want that help, say so.

> powers that be (i.e. you?) feel it's of no concern than so be it. Life

With all the e-mails this thread is generating, how could you think it
is of no concern to us?

> goes on, we find work arounds, and things proceed in a (somewhat)
> orderly fasion. I hope that those "powers" take note but if not then oh
> well, at least I did my part and spoke up and no one can say "why did
> that update fail on Christmas!" We all know now that it's possible that
> an FL update will appear on Christmas Eve and should plan and program
> accordingly. :)

Yes, true.

-- 
Eric Rostetter



From ismanager at ccbnpts.com  Tue Mar 29 23:23:17 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Tue, 29 Mar 2005 17:23:17 -0600
Subject: mysql-server
In-Reply-To: <1112138134.25ff49c919f0f@mail.ph.utexas.edu>
Message-ID: <002b01c534b6$49f08980$7202a8c0@ccb2vpjza>

> Eric Rostetter
> 
> Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:
> 
> > The overhead (work hours) is high if said downloads are on multiple
> > servers and updates must be run on each (as well as dependancy
> > checking). My dad always said "work smarter".
> 
> But is it "working smarter" if doing so results in your machines or
> services going down?  I'd say not.
> 

Yes it is if you know that updates will come out a random and un-uniform
times. Then you can plan ahead or program something that will correct
for the lack of forsight by those in charge of updates.

> > It's sort of just one of those times when multiple normally 
> unrelated
> > occurances happen at the same time (i.e. mysql update, 
> holiday, broken
> > restart function in said update). Many ways to fix it but I 
> think one
> > way to help would be to maybe schedule pending updates. 
> That might be a
> > problem but hey, this is a discussion right?
> 
> Yes, it is a discussion.  Your solution won't work. But maybe 
> we'll get
> a solution that does work by having this discussion.
> 
> -- 
> Eric Rostetter
> 

Actually I possed no solution except re-writing the cron script (and
that from a idea by Tom) that runs the auto update. Yum it's self is not
the problem here. If you feel somehow that is not fesable then please
explain why.

Now as to my SUGGESTION that updates be put out in a more conscientious
fasion, if you find that unworkable then so be it. Other's have no
problem structuring their updates in a manner that helps admins. That is
not to say you should or can, only you can determine that and from your
statements it's not possible for FL to do that. C'est la vie.

Been interesting guys.

Paul Pettit



From rostetter at mail.utexas.edu  Tue Mar 29 23:34:34 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Tue, 29 Mar 2005 17:34:34 -0600
Subject: mysql-server
In-Reply-To: <002b01c534b6$49f08980$7202a8c0@ccb2vpjza>
References: <002b01c534b6$49f08980$7202a8c0@ccb2vpjza>
Message-ID: <1112139274.7b882c147995f@mail.ph.utexas.edu>

Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:

> Actually I possed no solution except re-writing the cron script (and

You proposed the solution which is scheduling updates to avoid certain
days.  You call it a suggestion, but it was a suggestion to fix a problem,
and as such it is a solution.

> that from a idea by Tom) that runs the auto update. Yum it's self is not
> the problem here. If you feel somehow that is not fesable then please
> explain why.

I'm not sure what you want me to explain that hasn't already been covered.
 
> Now as to my SUGGESTION that updates be put out in a more conscientious
> fasion, if you find that unworkable then so be it. Other's have no
> problem structuring their updates in a manner that helps admins. That is

Almost no one does this.  Most people release security fixes and virus
updates when they are ready, not on a fixed schedule.  Red Hat (before
RHEL) always released fixes when they were ready, be that a weekend or
not.  We're carrying on that redhat tradition.

> not to say you should or can, only you can determine that and from your
> statements it's not possible for FL to do that. C'est la vie.
> 
> Been interesting guys.

You giving up already before we've fixed things?  You may, that's fine,
but maybe you should stay involved while we work to resolve some of
the issues you and others have brought up...

> Paul Pettit

-- 
Eric Rostetter



From ismanager at ccbnpts.com  Tue Mar 29 23:45:50 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Tue, 29 Mar 2005 17:45:50 -0600
Subject: mysql-server
In-Reply-To: <1112138734.e9c0f9e5bfbee@mail.ph.utexas.edu>
Message-ID: <002c01c534b9$701e8690$7202a8c0@ccb2vpjza>

> Eric Rostetter
> 
> Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:
> 
> > Heh, well do you happen to know when the yum auto update 
> runs? You are
> 
> When ever you tell it to.
> 

Ooooh, so tempting ...

Um, no. It runs when cron.daily runs and that runs at ONE time in the
day. Move the time cron.daily runs and you move the time a ton of other
things run.

Remember we are talking with the *stock* setup as detailed in the
documentation.

> > aware of the impact that FL's documentation has if you simply follow
> > step 4 and make no other changes?
> 
> So why don't you propose changes to the docs?
> 

Actually the docs really aren't a problem other than maybe a warning on
the impact of auto-updating for those less familure and maybe a list of
problematic major package other than kernel that should be excluded.

But the docs are spot on for setup and that's really what they are for
so no real issue there.

> > It is FL's documentation after all so
> 
> FL is a community.  The docs are the community's docs.  As part of the
> community, they are now your docs also.  If you find fault in them,
> help change them.
> 

Considering the above I'll see what I can do.

> > you should know that those using the yum auto update would 
> update Friday
> > MORNING at 4am or so (assuming that cron.daily is running per stock
> > settings).
> 
> And you implemented it, so hopefully *you* would know when it 
> would run,
> and change it if needed.
> 

Oh yes, I knew when it was to run. I just didn't expect an update right
before Easter. Just one of those things. If your worried about me trying
to shift blame you can stop. My sole goal was to point out that
releasing updates right before or on holidays was a bad idea. You
disagree, so there we are.

> But, as your discussion (not you) pointed out, the docs probably need
> updating.  It's now on my todo list because of your discussion.
> 
> > Look, all I wanted to do was point out a particular 
> situation. If the
> 
> You also pointed out a particular solution.  It was rejected. 
>  But some
> people would still like to help you and others to find 
> another solution.
> If you don't want that help, say so.
> 

Just why is scheduling updates (or limiting them to business days in
what ever TZ your in) bad? You rejected it but with no actual
explaination.

Anyway, people (inc. me) have already made suggestions that are
independent of FL being responsive. Thanks though, if I think I'll get
some help I'll contact you.

> > powers that be (i.e. you?) feel it's of no concern than so 
> be it. Life
> 
> With all the e-mails this thread is generating, how could you think it
> is of no concern to us?
> 

Because you have rejected the problem without explination of why you
feel this isn't a problem beyond the "you shouldn't use auto-updating"
or "it's a yum problem" answer of which neither is valid. As stewards of
these updates you bear a bit more responsibility than that. 

> > goes on, we find work arounds, and things proceed in a (somewhat)
> > orderly fasion. I hope that those "powers" take note but if 
> not then oh
> > well, at least I did my part and spoke up and no one can 
> say "why did
> > that update fail on Christmas!" We all know now that it's 
> possible that
> > an FL update will appear on Christmas Eve and should plan 
> and program
> > accordingly. :)
> 
> Yes, true.
> 
> -- 
> Eric Rostetter
> 

Lol!

Ah well. I'm out. Time for home.

Peace.

Paul Pettit



From ismanager at ccbnpts.com  Tue Mar 29 23:50:18 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Tue, 29 Mar 2005 17:50:18 -0600
Subject: mysql-server
In-Reply-To: <1112139274.7b882c147995f@mail.ph.utexas.edu>
Message-ID: <002d01c534ba$100dd2f0$7202a8c0@ccb2vpjza>

> Eric Rostetter
> 
> Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:
> > 
> > Been interesting guys.
> 
> You giving up already before we've fixed things?  You may, 
> that's fine,
> but maybe you should stay involved while we work to resolve some of
> the issues you and others have brought up...
> 
> > Paul Pettit
> 
> -- 
> Eric Rostetter
> 

Nope, not giving up per say but I forsee no real change in possitions.
I'll see how things look in the morning. 

It's Miller time for me. :)

Paul Pettit



From kelson at speed.net  Wed Mar 30 00:27:03 2005
From: kelson at speed.net (Kelson)
Date: Tue, 29 Mar 2005 16:27:03 -0800
Subject: mysql-server
In-Reply-To: <1111786407.11539.117.camel@serendipity.dogma.lan>
References: <1111767208.5462.43.camel@spider.joesauer.org>	<42444D2C.4040404@revsharecorp.com>	<20050325212412.GB10837@x.esc.rl.ac.uk>
	<1111786407.11539.117.camel@serendipity.dogma.lan>
Message-ID: <4249F257.5070002@speed.net>

Alexander Dalloz wrote:
> The issue is, that the init script does not
> take care for the case, that the MySQL root user has a password set
> (which is highly recommended) and the anonymous user removed.
> Unfortunately the RPM install does not care for a changed init script -
> changed for fixing the issue - and exchanges it with the wrong one
> again.

Also, every time I've upgraded I've had to adjust the following config line:

# chkconfig: - 78 12

to read:

# chkconfig: 345 78 12

Even when I was getting updates from Red Hat or straight from MySQL, I 
ran into problems where it would decide to remove the links from the 
runlevel directories, because that's what the chkconfig line in the 
initscript said.  The next time we had to install a new kernel, MySQL 
didn't start with the system.

The three numbers are:

1. runlevels in which to run the service (digits all run together)
2. start sequence position
3. end sequence position

 From what I can tell, when RPM upgrades the package it reruns chkconfig 
and restores the default setting of, well, not running MySQL.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>



From drees at greenhydrant.com  Wed Mar 30 00:44:05 2005
From: drees at greenhydrant.com (David Rees)
Date: Tue, 29 Mar 2005 16:44:05 -0800 (PST)
Subject: mysql-server
In-Reply-To: <002c01c534b9$701e8690$7202a8c0@ccb2vpjza>
References: <1112138734.e9c0f9e5bfbee@mail.ph.utexas.edu>
	<002c01c534b9$701e8690$7202a8c0@ccb2vpjza>
Message-ID: <2719.208.48.139.172.1112143445.squirrel@www.greenhydrant.com>

On Tue, March 29, 2005 3:45 pm, Pettit, Paul said:
>> > Heh, well do you happen to know when the yum auto update
>> > runs?
>>
>> When ever you tell it to.
>
> Ooooh, so tempting ...
>
> Um, no. It runs when cron.daily runs and that runs at ONE time in the
> day. Move the time cron.daily runs and you move the time a ton of other
> things run.
>
> Remember we are talking with the *stock* setup as detailed in the
> documentation.

The *stock* setup *works* for the vast majority of FL users.  You
obviously have different needs.  I've suggested a solution and even wrote
a small script in attempt to solve your problem.  Did you see it?

If you wan yum to run at 7:00AM Mon-Fri, it's pretty simple to set it up
to do so.  Make sure that the yum service is off (`service yum stop;
chkconfig yum off`), copy the yum.cron script somewhere you see fit,
modify it to not check the config status of yum and not to sleep some
random time between 0 and 120 minutes and add the following to root's
crontab:

0 7 * * 1,2,3,4,5 /etc/<somewhere>/yum.cron

> Just why is scheduling updates (or limiting them to business days in
> what ever TZ your in) bad? You rejected it but with no actual
> explaination.

When it comes to security updates (the goal of FL), the sooner these
updates are released to the community, the better.  If you would only like
updates to be applied during a specific time period, see my solution
above.

> Because you have rejected the problem without explination of why you
> feel this isn't a problem beyond the "you shouldn't use auto-updating"
> or "it's a yum problem" answer of which neither is valid. As stewards of
> these updates you bear a bit more responsibility than that.

See above.

-Dave



From cra at WPI.EDU  Wed Mar 30 01:18:07 2005
From: cra at WPI.EDU (Chuck R. Anderson)
Date: Tue, 29 Mar 2005 20:18:07 -0500
Subject: mysql-server
In-Reply-To: <4249F257.5070002@speed.net>
References: <1111767208.5462.43.camel@spider.joesauer.org>
	<42444D2C.4040404@revsharecorp.com>
	<20050325212412.GB10837@x.esc.rl.ac.uk>
	<1111786407.11539.117.camel@serendipity.dogma.lan>
	<4249F257.5070002@speed.net>
Message-ID: <20050330011807.GM21545@angus.ind.WPI.EDU>

On Tue, Mar 29, 2005 at 04:27:03PM -0800, Kelson wrote:
> Even when I was getting updates from Red Hat or straight from MySQL, I 
> ran into problems where it would decide to remove the links from the 
> runlevel directories, because that's what the chkconfig line in the 
> initscript said.  The next time we had to install a new kernel, MySQL 
> didn't start with the system.

That is a bug in the RPM %post scriptlet.  It should not be running
"chkconfig --add" unless this is the first instance of a package 
install, not an upgrade.



From cra at WPI.EDU  Wed Mar 30 01:30:08 2005
From: cra at WPI.EDU (Chuck R. Anderson)
Date: Tue, 29 Mar 2005 20:30:08 -0500
Subject: Staggered local repo mirrors [was Re: mysql-server]
In-Reply-To: <002c01c534b9$701e8690$7202a8c0@ccb2vpjza>
References: <1112138734.e9c0f9e5bfbee@mail.ph.utexas.edu>
	<002c01c534b9$701e8690$7202a8c0@ccb2vpjza>
Message-ID: <20050330013008.GN21545@angus.ind.WPI.EDU>

On Tue, Mar 29, 2005 at 05:45:50PM -0600, Pettit, Paul wrote:
> Oh yes, I knew when it was to run. I just didn't expect an update right
> before Easter. Just one of those things. If your worried about me trying
> to shift blame you can stop. My sole goal was to point out that
> releasing updates right before or on holidays was a bad idea. You
> disagree, so there we are.

I have what might be a workable solution.  Set up a local repository
that you mirror manually or on a schedule you prefer from an official
repository mirror, and point all your auto updating clients at that. 
Then you can choose exactly when updates get pushed out by modifying
the schedule that the local mirror is populated.  Holiday coming up? 
Turn off the mirror job.

As a bonus, you could even have different classes of clients, like
critical servers, backup servers, test boxes, and desktop systems, all
using different local yum repos.  Do a staggered rollout to the local
yum repos, starting with the test boxes, moving up to desktops, backup
servers, and finally critical servers once everything is verified
working properly.



From kelson at speed.net  Wed Mar 30 01:36:49 2005
From: kelson at speed.net (Kelson)
Date: Tue, 29 Mar 2005 17:36:49 -0800
Subject: mysql-server
In-Reply-To: <20050330011807.GM21545@angus.ind.WPI.EDU>
References: <1111767208.5462.43.camel@spider.joesauer.org>	<42444D2C.4040404@revsharecorp.com>	<20050325212412.GB10837@x.esc.rl.ac.uk>	<1111786407.11539.117.camel@serendipity.dogma.lan>	<4249F257.5070002@speed.net>
	<20050330011807.GM21545@angus.ind.WPI.EDU>
Message-ID: <424A02B1.50102@speed.net>

Chuck R. Anderson wrote:
> On Tue, Mar 29, 2005 at 04:27:03PM -0800, Kelson wrote:
>>Even when I was getting updates from Red Hat or straight from MySQL, I 
>>ran into problems where it would decide to remove the links from the 
>>runlevel directories, because that's what the chkconfig line in the 
>>initscript said.  The next time we had to install a new kernel, MySQL 
>>didn't start with the system.
> 
> 
> That is a bug in the RPM %post scriptlet.  It should not be running
> "chkconfig --add" unless this is the first instance of a package 
> install, not an upgrade.

A known bug, or just something I ran into switching between the "mysql" 
and "MySQL" packages?

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>



From cra at WPI.EDU  Wed Mar 30 01:37:00 2005
From: cra at WPI.EDU (Chuck R. Anderson)
Date: Tue, 29 Mar 2005 20:37:00 -0500
Subject: mysql-server
In-Reply-To: <424A02B1.50102@speed.net>
References: <1111767208.5462.43.camel@spider.joesauer.org>
	<42444D2C.4040404@revsharecorp.com>
	<20050325212412.GB10837@x.esc.rl.ac.uk>
	<1111786407.11539.117.camel@serendipity.dogma.lan>
	<4249F257.5070002@speed.net>
	<20050330011807.GM21545@angus.ind.WPI.EDU>
	<424A02B1.50102@speed.net>
Message-ID: <20050330013700.GO21545@angus.ind.WPI.EDU>

On Tue, Mar 29, 2005 at 05:36:49PM -0800, Kelson wrote:
> >That is a bug in the RPM %post scriptlet.  It should not be running
> >"chkconfig --add" unless this is the first instance of a package 
> >install, not an upgrade.
> 
> A known bug, or just something I ran into switching between the "mysql" 
> and "MySQL" packages?

I don't know.  I didn't look at the packages.  I just know from your
description of the behavior what is most likely happening.  User
customizations of service runlevels using "chkconfig --level abc
on/off" should stick across upgrades.  "chkconfig --add" would wipe
those changes out, going back to the defaults specified in the
initscript's chkconfig: line.  That's why that command shouldn't be 
running on upgrades.



From marcdeslauriers at videotron.ca  Wed Mar 30 01:39:30 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Tue, 29 Mar 2005 20:39:30 -0500
Subject: mysql-server
In-Reply-To: <002801c534b4$b7c36240$7202a8c0@ccb2vpjza>
References: <002801c534b4$b7c36240$7202a8c0@ccb2vpjza>
Message-ID: <1112146771.9907.9.camel@mdlinux>

On Tue, 2005-03-29 at 17:12 -0600, Pettit, Paul wrote:
> Heh, well do you happen to know when the yum auto update runs? You are
> aware of the impact that FL's documentation has if you simply follow
> step 4 and make no other changes? It is FL's documentation after all so
> you should know that those using the yum auto update would update Friday
> MORNING at 4am or so (assuming that cron.daily is running per stock
> settings).
> 

Oh, you were off on Friday. I understand now. I was under the impression
people had Monday off. Yes, btw, I know when yum auto update runs.

> Look, all I wanted to do was point out a particular situation. If the
> powers that be (i.e. you?) feel it's of no concern than so be it. Life
> goes on, we find work arounds, and things proceed in a (somewhat)
> orderly fasion. I hope that those "powers" take note but if not then oh
> well, at least I did my part and spoke up and no one can say "why did
> that update fail on Christmas!" We all know now that it's possible that
> an FL update will appear on Christmas Eve and should plan and program
> accordingly. :)
> 

I didn't say it was of no concern. Actually, I think you're right about
being careful around holidays. We should try to not release official
updates near weekends and holidays. What does everyone think?

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050329/31dc6f02/attachment.sig>

From marcdeslauriers at videotron.ca  Wed Mar 30 01:59:45 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Tue, 29 Mar 2005 20:59:45 -0500
Subject: mysql-server
In-Reply-To: <002801c534b4$b7c36240$7202a8c0@ccb2vpjza>
References: <002801c534b4$b7c36240$7202a8c0@ccb2vpjza>
Message-ID: <1112147985.9907.12.camel@mdlinux>

On Tue, 2005-03-29 at 17:12 -0600, Pettit, Paul wrote:
> I'll see what I can do. Not sure if I have an account there but if not
> I'll make one when I get a few minutes free. Honestly though I think
> othes would be better versed in the actual bug. I didn't know what
> caused it till I read it here.

OK, I opened a bug for that here:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152531

If people could add some comments/theories about mysql not restarting to
that bug, I'll get it fixed in time for the next update.

Thanks,

Marc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050329/0664bfe9/attachment.sig>

From drees at greenhydrant.com  Wed Mar 30 02:36:59 2005
From: drees at greenhydrant.com (David Rees)
Date: Tue, 29 Mar 2005 18:36:59 -0800 (PST)
Subject: mysql-server
In-Reply-To: <1112146771.9907.9.camel@mdlinux>
References: <002801c534b4$b7c36240$7202a8c0@ccb2vpjza>
	<1112146771.9907.9.camel@mdlinux>
Message-ID: <49014.208.48.139.170.1112150219.squirrel@www.greenhydrant.com>

On Tue, March 29, 2005 5:39 pm, Marc Deslauriers said:
>
> I didn't say it was of no concern. Actually, I think you're right about
> being careful around holidays. We should try to not release official
> updates near weekends and holidays. What does everyone think?

I work weekends and all public holidays here in the states, but have all 
Mondays, Tuesdays, Wednesdays off.  It would be extremely convenient to me
if FL would only release updates on weekends and holidays, because then
I'll be in the office in case something breaks.

Insert tongue-in-cheek here.  :-P

It's already been said why restricting release periods is a bad idea, but
I'll say it again.  Security updates (the primary reason FL exists) need
to be released ASAP, not when it's convenient for all of its users. 
Especially if you are using mirrors which tend to lag behind the primary
for some period of time.  It doesn't take much time for a cracker to write
a worm which might take advantage of some exploit, the less time my
systems are vulnerable to attack the better.  If you wish to submit your
machines to longer periods of vulnerability, risk your own machines, not
everyone else's too.

If you are concerned that a weekend update will break your machine,
there's already been a number of suggestions in this thread on how to work
around that issue.  It would be nice to have a RHN-style system, but as
far as I know one doesn't exist unless you are willing to pay RHN license
fees in which case you wouldn't be here...

-Dave



From marcdeslauriers at videotron.ca  Wed Mar 30 03:59:23 2005
From: marcdeslauriers at videotron.ca (Marc Deslauriers)
Date: Tue, 29 Mar 2005 22:59:23 -0500
Subject: mysql-server
In-Reply-To: <49014.208.48.139.170.1112150219.squirrel@www.greenhydrant.com>
References: <002801c534b4$b7c36240$7202a8c0@ccb2vpjza>
	<1112146771.9907.9.camel@mdlinux>
	<49014.208.48.139.170.1112150219.squirrel@www.greenhydrant.com>
Message-ID: <1112155163.10567.4.camel@mdlinux>

On Tue, 2005-03-29 at 18:36 -0800, David Rees wrote:
> I work weekends and all public holidays here in the states, but have all 
> Mondays, Tuesdays, Wednesdays off.  It would be extremely convenient to me
> if FL would only release updates on weekends and holidays, because then
> I'll be in the office in case something breaks.
> 
> Insert tongue-in-cheek here.  :-P
> 
> It's already been said why restricting release periods is a bad idea, but
> I'll say it again.  Security updates (the primary reason FL exists) need
> to be released ASAP, not when it's convenient for all of its users. 
> Especially if you are using mirrors which tend to lag behind the primary
> for some period of time.  It doesn't take much time for a cracker to write
> a worm which might take advantage of some exploit, the less time my
> systems are vulnerable to attack the better.  If you wish to submit your
> machines to longer periods of vulnerability, risk your own machines, not
> everyone else's too.

Yeah, that makes sense too.

Well, I guess we'll still release updates as they're ready.

Marc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050329/e36af37f/attachment.sig>

From mattdm at mattdm.org  Wed Mar 30 04:13:40 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 29 Mar 2005 23:13:40 -0500
Subject: state of bugzilla (and, current kernel root exploits....)
In-Reply-To: <20050329193350.GK29340@urchin.earth.li>
References: <20050329144737.GA17121@jadzia.bu.edu>
	<20050329193350.GK29340@urchin.earth.li>
Message-ID: <20050330041340.GA16599@jadzia.bu.edu>

On Tue, Mar 29, 2005 at 08:33:50PM +0100, Dominic Hargreaves wrote:
> I don't know what the hold-up is, but it seems that the import hasn't
> occurred yet. However there are no open kernel bugs that I can spot in
> bugzilla.fedora.us, so feel free to open new legacy bugs on
> bugzilla.redhat.com. The product is there and ready to go AFAIK.

Done: <https://bugzilla.redhat.com/beta/show_bug.cgi?id=152532>

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From hjp+fedora-legacy at wsr.ac.at  Wed Mar 30 10:52:57 2005
From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer)
Date: Wed, 30 Mar 2005 12:52:57 +0200
Subject: mysql-server
In-Reply-To: <001101c534ac$e9b6d5a0$7202a8c0@ccb2vpjza>
References: <20050329144712.A5987@mail.harddata.com>
	<001101c534ac$e9b6d5a0$7202a8c0@ccb2vpjza>
Message-ID: <20050330105257.GC29880@wsr.ac.at>

On 2005-03-29 16:16:10 -0600, Pettit, Paul wrote:
> The problem is that as setup (via FL's own documentation) there is no
> granular control. The default is 'on' or 'off' and that's it.

That's what cron and shell-scripts are for. One tool for every job. 

> Not very handy when you add to that FL's policy of pushing updates out
> as soon as possible without consideration to timing. It's not a bad
> policy but ...

I agree with others that FL should NOT consider timing. Local policies
vary wildly between organisations. One organization may have a policy to
make updates only on monday to thursday, while another may have a policy
to make them only on sunday morning (I do know one company where changes
on production servers are only allowed on sunday from 00:00 to 06:00).
These are local policies, and they should be implemented locally. FL
cannot know about them and I think it is not a good idea for FL to
decide for its users when they should update their systems. 

	hp

-- 
   _  | Peter J. Holzer \Beta means "we're down to fixing misspelled comments in
|_|_) | Sysadmin WSR     \the source, and you might run into a memory leak if 
| |   | hjp at wsr.ac.at     \you enable embedded haskell as a loadable module and
__/   | http://www.hjp.at/ \write your plugins upside-down in lisp". --ae at op5.se
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 388 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050330/8ac0f9aa/attachment.sig>

From hjp+fedora-legacy at wsr.ac.at  Wed Mar 30 10:58:15 2005
From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer)
Date: Wed, 30 Mar 2005 12:58:15 +0200
Subject: mysql-server
In-Reply-To: <4249bc86.33c30268.6586.ffff8da9@mx.gmail.com>
References: <20050329130050.A3532@mail.harddata.com>
	<4249bc86.33c30268.6586.ffff8da9@mx.gmail.com>
Message-ID: <20050330105815.GD29880@wsr.ac.at>

On 2005-03-29 14:37:14 -0600, Matthew Nuzum wrote:
> > On Tue, Mar 29, 2005 at 01:05:51PM -0600, Eric Rostetter wrote:
> > > Maybe yum could be modified to allow you to download the updates to the
> > > cache without installing them
[...]
> I suspect that you could just install a SQUID cache (not in transparent
> proxying mode) and tell yum to use it as a proxy server, allowing you to
> basically just proxy your updates.

Yep. That's what we use here (with apt instead of yum, but same
principle). You just have to set maximum_object_size in squid larger
than the largest RPM, otherwise squid will cache only small RPMs and not
the large ones.

	hp

-- 
   _  | Peter J. Holzer \Beta means "we're down to fixing misspelled comments in
|_|_) | Sysadmin WSR     \the source, and you might run into a memory leak if 
| |   | hjp at wsr.ac.at     \you enable embedded haskell as a loadable module and
__/   | http://www.hjp.at/ \write your plugins upside-down in lisp". --ae at op5.se
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 388 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050330/42651ead/attachment.sig>

From rostetter at mail.utexas.edu  Wed Mar 30 15:06:48 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Wed, 30 Mar 2005 09:06:48 -0600
Subject: mysql-server
In-Reply-To: <009501c5349e$2eaf6190$7202a8c0@ccb2vpjza>
References: <009501c5349e$2eaf6190$7202a8c0@ccb2vpjza>
Message-ID: <1112195208.b768cfa1990cf@mail.ph.utexas.edu>

Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:

> > "Best Practices" dictate that you simply don't do automatic updates on
> > a production machine (whether linux, windows, solaris, or
> > other).  This
> > has nothing to do with FL per se.
> >
> 
> Most would say that being able to download overnight or automatically
> any update that came out, that has passed through QA, and has been maked
> as "critical", in a timely manner is a "best practice". In fact if you

For machines which are not critical, yes.  For critical machines, no.
Critical machines/services (machines or services for which you can not
"afford" in some metric downtime) should never do unattended updates
as they may create a machine/service failure or malfunction.

> have a sever that is in danger of being compromised unless said update
> is done it's not just a "best practice" it's a requirement for continued
> employment.

Maybe you need to look at other ways to protect it instead?  Maybe a 
firewall, or disabling or removing a vulnerable service, or some other
method until you can safely test and install the updates.

In fact, if you could just use automatted updates, then your job is
really in danger (for reduced hours at least) since they don't need
you around to do updates; just turn them on automatically.

> If QA is not robust enough to trust these updates on production servers

No, QA is not, and can not, verify that it will work for all users.

> (and just how many people here are still "playing" with 7.3 or 9?) then

Probably lots are "playing" with it, just as many (myself included) use
them in production (no playing).  Not sure what you mean to imply with
that comment really.

> I think there is an underlying problem.

Yes.  The underlying problem is people incorrectly think they can use
automatic updates on production/critical machines and obviously the
industry in general as well as FL has not done enough to educate people
that this isn't the case.

> > > To limit
> > > people to manually acting on updates devalues FL's service below
> > > Microsoft.
> >
> > No, it differs in no way from Microsofts updates.  Microsoft
> > also states
> > that you should not apply automatic updates to
> > production/critical servers.
> >
> 
> Incorrect!

No, sorry, it is correct.

> All critical updates that M$ puts out are REQUIRED for production
> servers, it's not an option even though many admins think it is (and
> thus look at the number of hacked systems).

The fact that they are "required" does not mean you should automatically
install them.  Microsoft's policy is you should test them first, then 
install them.  They do not recommend you automatically install new patches
on production/critical machines without testing or at least monitoring
the install.

> The patches they put out
> have passed QA and are certified to fix the related issue.

Yes, but they are not certified to not crash your machine, toast your
services, or otherwise shutdown your production.  And even though they
may say they fix the related issue, sometimes they don't (or only partially
fix it).  But that is another issue.  Whether it fixes the issue or not
is not the issue of this thread. The issue of this thread is can you safely
install the updates automatically without any monitoring or testing, and
the answer is no (whether the update comes from Microsoft or FL).

> The same is true for RHEL, the updates they put out are good for prime
> time. It would be worthless to have updates if you first had to try them
> out on a test server just to see if the server will run.

But yet this is the case.  So by your theory RHEL updates are worthless.

I can't count the number of time QA'd software from Dell and Red Hat has
caused problem on production Dell PowerEdge 2650 machines.

> If your stand is that all updates need to be further tested when you
> download them from FL thats just ... eh?

In a perfect world, yes, you would do that for all FL and Microsoft and
Dell and Sun and who-ever-else's updates.  Now in the real world, it
may not be practical, and indeed I don't usually test them first. But
on my critical machines, I only install them by hand.  I'd never install
them automatically.  And once they are installed, I test/verify the
functionality of the machine to make sure (best I can) it still works.

I would notice right away after a mysql update if the mysql server wasn't
running.

> Well yeah maybe if they relate to other apps (or other apps rely on
> them) but where does that figure into the mySQL crash after update?

It doesn't.

> Simply put it doesn't, the package updated fine, didn't break anything,
> and failed to reboot on it's own.

And had you followed minimal best practices (watch the update, test it
after wards) you would have found this out immediately and fixed it.

Personally I wouldn't even update mysql without first making a backup
of the databases, just in case.  That would preclude using an automatted
update tool via cron.

> This happened on a holiday thus
> compounding the problem for a (unlucky) few. It's not biterness but
> concern for future updates and the haphazard way they are being put out.

There is nothing haphazard about the way they are being put out, and they
are being put out asap because that is they way the majority of people 
want them put out.

> But if I'm the only one worried then ... meh. I'll live and I'm sure the
> world won't end if this is pushed aside.

You seem to think it is going to be pushed aside, so much that you don't
seem to want to help.  I don't know why you feel this way.  There is much
that can be done to help with the situation, such as updating the docs
to address the issue, etc.  I have no intention to push this aside, just
as I have no intention to change the way releases are done.

> My point (which has been lost and was an opinion btw) was that to help
> the end users from getting bit by a major package update going south
> that updates be distrubuted in a timely manner but taking into
> consideration that some days of the month are bad days. Since most here
> are euro or american it's not that hard to figure out the big ones.

Yes, as I pointed out, Monday in my time zone is not Monday in other
people's time zone, so it is difficult to do.
 
> Tom actually had a good idea (sarcastic though it was) in that more
> control of yum is needed.

I also suggested maybe modifying yum.  But I guess my opinion is of no
value to you, since I disagree with your primary goal of changing the
way releases are issued.  But then again, yum is a project separate
from FL, so this may not be the best place to discuss this issue.

> To that I say "duh!" now that I see that yum
> works too black/white for most admin's (at least me) needs. Since I'm a
> programmer I'll deal with the random timing of updates that FL puts out
> by controling when yum really updates, not just every freaking day like
> they have it set at.

Good.  That's good progress.
 
> But again I reiterate, releasing updates on certain days is ***IMHO*** a
> bad idea because not all are willing / able to fix yum on their own to
> ensure that they aren't on holiday when the next big package downloads
> then pukes (manually updating not included).

See above.  Best practices dictates that you don't use automatted updates.
If you do, you're assuming the risk inherent in doing so.

> Take MHO for what it's worth or whatever little you *think* it's worth.

I think your opinion is worth the world.  And a lot of good ideas have
come from this discussion, some of which will help FL and its users
in the future.  But, none-the-less, you are fighting a losing battle
trying to change the release schedule; it just isn't practical or 
desirale.  That doesn't mean FL can't help you and others though, in
other ways, to help better the situation.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Wed Mar 30 15:17:33 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Wed, 30 Mar 2005 09:17:33 -0600
Subject: mysql-server
In-Reply-To: <002c01c534b9$701e8690$7202a8c0@ccb2vpjza>
References: <002c01c534b9$701e8690$7202a8c0@ccb2vpjza>
Message-ID: <1112195853.07c92d10e09d1@mail.ph.utexas.edu>

Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:

> > Eric Rostetter
> >
> > Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:
> >
> > > Heh, well do you happen to know when the yum auto update
> > runs? You are
> >
> > When ever you tell it to.
> >
> 
> Ooooh, so tempting ...

For some.

> Um, no. It runs when cron.daily runs and that runs at ONE time in the
> day. Move the time cron.daily runs and you move the time a ton of other
> things run.

It runs when you told it to.  You put it in cron.daily, so it runs
when cron.daily runs.  You could have told it to run at any time you
wanted, in any way you wanted.

> Remember we are talking with the *stock* setup as detailed in the
> documentation.

Assuming you made the choice to enable auto updates per the docs.

> > > aware of the impact that FL's documentation has if you simply follow
> > > step 4 and make no other changes?
> >
> > So why don't you propose changes to the docs?
> >
> 
> Actually the docs really aren't a problem other than maybe a warning on
> the impact of auto-updating for those less familure and maybe a list of
> problematic major package other than kernel that should be excluded.

Exactly what I mean.

> But the docs are spot on for setup and that's really what they are for
> so no real issue there.

No, if the docs offer the info to do auto-updates, then they are also
the correct place to document the issues involved with auto-updates.

> > > It is FL's documentation after all so
> >
> > FL is a community.  The docs are the community's docs.  As part of the
> > community, they are now your docs also.  If you find fault in them,
> > help change them.
> >
> 
> Considering the above I'll see what I can do.

That would be wonderful.  I'll modify them when I get a chance, unless
someone beats me to it, but it could be a few days before I get to it.

Anyone who wants to update them, please feel free to do so.  You can
modify them in the wiki, or modify them and post a diff to the mailing
list, or contact me directly via email about changes.

> Just why is scheduling updates (or limiting them to business days in
> what ever TZ your in) bad? You rejected it but with no actual
> explaination.

Because what good does it do to limit them in my TZ when someone else
is in another TZ?  Because I may not know what your holiday schedule is.
Because you may simply be on vacation (no official holiday) and have
the same problem.  Because the delay my result in your not getting the
security update until after your machine was hacked, even though the
patch was available and ready.  Do I really need to go on?
 
> Anyway, people (inc. me) have already made suggestions that are
> independent of FL being responsive. Thanks though, if I think I'll get
> some help I'll contact you.

I still can't figure out why you say FL isn't responsive.  I've already
committed to changes to help with this situation.  Not to mention all
the mails that people have shared about it.

> > With all the e-mails this thread is generating, how could you think it
> > is of no concern to us?
> 
> Because you have rejected the problem without explination of why you

NO!  We've not rejected the problem!  We've rejected your solution.

> feel this isn't a problem beyond the "you shouldn't use auto-updating"
> or "it's a yum problem" answer of which neither is valid. As stewards of
> these updates you bear a bit more responsibility than that.

And we're taking such responsibility.  Sorry if you can't see that.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Wed Mar 30 15:32:14 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Wed, 30 Mar 2005 09:32:14 -0600
Subject: mysql-server
In-Reply-To: <1112146771.9907.9.camel@mdlinux>
References: <002801c534b4$b7c36240$7202a8c0@ccb2vpjza>
	<1112146771.9907.9.camel@mdlinux>
Message-ID: <1112196734.d3d5550692c0d@mail.ph.utexas.edu>

Quoting Marc Deslauriers <marcdeslauriers at videotron.ca>:

> I didn't say it was of no concern. Actually, I think you're right about
> being careful around holidays. We should try to not release official
> updates near weekends and holidays. What does everyone think?

I think that is wrong, except for release for "unknown" vulnerabilities
(where all vendors co-ordinate the release).

Security patches should come out asap.  If we delay them, we may be
allowing people to get hacked.  We only release security updates (not
bug fixes) so there is no real way to delay them.  We can, however,
try to "rush" them to get them out earlier if we know a holiday is
coming up, etc.  As long as we still do proper QA, etc.  This may meen
simply that the package publishes need to make sure they get them out
quickly if a holiday/weekend is coming up, etc.

We can't effectively schedule around holidays and weekends, since timezones
and cultural holidays make that too difficult.

The worst hacking time in the US is actually over the Thanksgiving day
period (Wednesday through Sunday of that week) and over the "Christmas
break" period (when schools are out, usually late December until early
January).  To delay releasing security releases during these periods
when the hacking level is highly elevated would not be a wise move
for a security-related service group, IMHO.

> Marc.

-- 
Eric Rostetter



From drees at greenhydrant.com  Wed Mar 30 16:19:02 2005
From: drees at greenhydrant.com (David Rees)
Date: Wed, 30 Mar 2005 08:19:02 -0800
Subject: mysql-server
In-Reply-To: <20050330151121.M15363@mm-vanecek.cc>
References: <Pine.LNX.4.61.0503291826140.24265@risby.gatekeeper.ltd.uk>	<007601c53487$83b9d330$7202a8c0@ccb2vpjza>	<1447.208.48.139.172.1112134456.squirrel@www.greenhydrant.com>
	<20050330151121.M15363@mm-vanecek.cc>
Message-ID: <424AD176.6020806@greenhydrant.com>

Mike Vanecek wrote, On 3/30/2005 7:12 AM:
> 
> To each his own, however, I do not use the cron.daily version, but use a 
> crontab entry:
> 
> # run yum check for updates daily and mail results to root
> 0 5 * * * root /usr/bin/yum check-update 2>&1 | mail -s "yum check-update 
> output" root

The biggest problem I had with doing what you did is that it emails you 
every day with the output from yum regardless of whether or not there is 
an update.

My script ends up only emailing me when it found an update to apply.

-Dave



From ismanager at ccbnpts.com  Wed Mar 30 16:25:24 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Wed, 30 Mar 2005 10:25:24 -0600
Subject: mysql-server
In-Reply-To: <2719.208.48.139.172.1112143445.squirrel@www.greenhydrant.com>
Message-ID: <009701c53545$137b7240$7202a8c0@ccb2vpjza>

> David Rees wrote:
> 
> On Tue, March 29, 2005 3:45 pm, Pettit, Paul said:
> >> > Heh, well do you happen to know when the yum auto update
> >> > runs?
> >>
> >> When ever you tell it to.
> >
> > Ooooh, so tempting ...
> >
> > Um, no. It runs when cron.daily runs and that runs at ONE 
> time in the
> > day. Move the time cron.daily runs and you move the time a 
> ton of other
> > things run.
> >
> > Remember we are talking with the *stock* setup as detailed in the
> > documentation.
> 
> The *stock* setup *works* for the vast majority of FL users.  You
> obviously have different needs. 
>

No, not much different than everyone else. 

I only possed an opinion (for which I have been thoroughly reamed for)
in regards to timing the release of updates. My only mistake was not
thinking of the problem on a more global scale in relation to timed
releases. It's apparent that this must be done based on each persons
local conditions. I had incorrectly thought it was something that FL
might want to control or lend a hand dealing with.

> I've suggested a solution and even wrote
> a small script in attempt to solve your problem.  Did you see it?
> 

Yes I did and it's the bet response of all the posts here. I thank you
for actually trying to solve the problem, that's what a community is
for. Saddly you're the only one that really did that. Tom had the same
idea but (heh) did it in less useful terminology. :)

I'm looking at your script and I've made another (in Perl) that has a
bit more granular control to it. I'm not much of a shell scripter so if
I use your script it wil probably be 'as is'.

I really appriciate the help man. 

> If you wan yum to run at 7:00AM Mon-Fri, it's pretty simple 
> to set it up
> to do so.  Make sure that the yum service is off (`service yum stop;
> chkconfig yum off`), copy the yum.cron script somewhere you see fit,
> modify it to not check the config status of yum and not to sleep some
> random time between 0 and 120 minutes and add the following to root's
> crontab:
> 
> 0 7 * * 1,2,3,4,5 /etc/<somewhere>/yum.cron
> 

Yeah that will work for now but dealing with holidays is a bit more
tricky. Yum nor Crom really don't have any method for dealing with it
and I'm not aware of another job scheduler for linux that would resolve
the core issue.

There in is the nut I need to crack. FL will be of no help in dealing
with it and I can see why: tz issues, lack of ownership, no drive to
resolve, and the mantra of security (updates out asap when "ready", not
that that's bad).

I'll have to do some more programing and I'll try and send out the
improved script (if I get it to work well) so others can use it. Did a
test run but it took like 3 hours to run and I'm not sure why. :P

> > Just why is scheduling updates (or limiting them to business days in
> > what ever TZ your in) bad? You rejected it but with no actual
> > explaination.
> 
> When it comes to security updates (the goal of FL), the sooner these
> updates are released to the community, the better.  If you 
> would only like
> updates to be applied during a specific time period, see my solution
> above.
> 

Actually Peter put it better:
|> Peter J. Holzer
|> 
|> I agree with others that FL should NOT consider timing. Local
policies
|> vary wildly between organisations. One organization may have 
|> a policy to
|> make updates only on monday to thursday, while another may 
|> have a policy
|> to make them only on sunday morning (I do know one company 
|> where changes
|> on production servers are only allowed on sunday from 00:00 to
06:00).
|> These are local policies, and they should be implemented locally. FL
|> cannot know about them and I think it is not a good idea for FL to
|> decide for its users when they should update their systems. 
|> 
|> 	hp

Simply put the problem is far to complicated for FL to deal with thus
they feel it's not their problem. Its up to the local admins to find a
solution, which is fine as I'm sure we are all up to it. I only thought
that FL might try and help but as I said it's too complex for them (as
many global issues are for many support service geared organizations).

The documentation however will need to be changed. I'm working on that
and will try and edit it once I figure out wiki (never used it before).

> > Because you have rejected the problem without explination of why you
> > feel this isn't a problem beyond the "you shouldn't use 
> auto-updating"
> > or "it's a yum problem" answer of which neither is valid. 
> As stewards of
> > these updates you bear a bit more responsibility than that.
> 
> See above.
> 
> -Dave
> 

I still feel they hold some responsibility in regards to addressing this
but they feel that they are only responcible for hosting the docs, the
update files, and coordinating testing. Understandable, more than that
is probably outside the scope of their ability. Releasing updates as
soon as they are up is the only compromise FL is capable of considering
all the above. I don't hold any animosity for that, it's just the way it
is.

Thanks Dave, I'll get back to you with a script and see what you think.
:)

Paul Pettit



From michal at harddata.com  Wed Mar 30 16:49:27 2005
From: michal at harddata.com (Michal Jaegermann)
Date: Wed, 30 Mar 2005 09:49:27 -0700
Subject: state of bugzilla (and, current kernel root exploits....)
In-Reply-To: <20050330041340.GA16599@jadzia.bu.edu>;
	from mattdm@mattdm.org on Tue, Mar 29, 2005 at 11:13:40PM -0500
References: <20050329144737.GA17121@jadzia.bu.edu>
	<20050329193350.GK29340@urchin.earth.li>
	<20050330041340.GA16599@jadzia.bu.edu>
Message-ID: <20050330094927.B28662@mail.harddata.com>

On Tue, Mar 29, 2005 at 11:13:40PM -0500, Matthew Miller wrote:
> On Tue, Mar 29, 2005 at 08:33:50PM +0100, Dominic Hargreaves wrote:
> > I don't know what the hold-up is, but it seems that the import hasn't
> > occurred yet. However there are no open kernel bugs that I can spot in
> > bugzilla.fedora.us, so feel free to open new legacy bugs on
> > bugzilla.redhat.com. The product is there and ready to go AFAIK.
> 
> Done: <https://bugzilla.redhat.com/beta/show_bug.cgi?id=152532>

By "Done" you mean that you managed to enter that report or that
old data were imported? I tried to search for all Legacy bugs
and I ended up with eight reports.  Two closed, one of these
#152532, and #152585 seems to be really a comment to #152583.

I also wonder about "Version" field which is really a distribution
tag.  It looks like that it can be set only to "core1", or "rhl9"
or "rhl7.3" in an exclusive way.  If there is a bug which affects
multiple distributions, which most often is the case although
patch particulars may differ, then a bug report should be cloned
across all these?  In particular #152532 clearly affects not
only rhl9 but it is marked as such.

   Michal



From ismanager at ccbnpts.com  Wed Mar 30 16:51:33 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Wed, 30 Mar 2005 10:51:33 -0600
Subject: mysql-server
In-Reply-To: <1112195208.b768cfa1990cf@mail.ph.utexas.edu>
Message-ID: <00a001c53548$ba9aed00$7202a8c0@ccb2vpjza>

> Eric Rostetter
> 
[snip lots of defensive mumblings]
> 
> I think your opinion is worth the world.  And a lot of good ideas have
> come from this discussion, some of which will help FL and its users
> in the future.  But, none-the-less, you are fighting a losing battle
> trying to change the release schedule; it just isn't practical or 
> desirale.  That doesn't mean FL can't help you and others though, in
> other ways, to help better the situation.
> 
> -- 
> Eric Rostetter
> 

I can't see how anyone could believe you when you say "your opinion is
worth the world". You've done nothing but attack me and my thoughts on
the subject. I guess you value my opinion as it gives you ammo to shoot
me with.

As for help?! No, not you, you have not helped at all. I'll tell you who
has helped: Michal Jaegermann, Alan M. Evans, and Dave Rees. They put
forth SOLUTIONS ... you sir only put forth defensive posts and harped on
my every statement. Then when it looked like I was going to "leave" the
discussion you tried doing some parting shots. Contemptable.

It was never a battle in my mind (don't bother responding, you DO NOT
know what I think) but an opinion that you took as an atttack on how FL
runs. I posted it not to change anything but to have people think about
it. You felt otherwise. I thank providance that there are others on this
list that were not so defensive on the subject and were willing to see
if there was a ready solution that ALL could use. As well as help get my
mind around the real reasons that FL can't do much more than they
already are.

It will be interesting to see your comments should I put up document
edits. I suspect there will be more of the same.

Paul Pettit



From michal at harddata.com  Wed Mar 30 17:17:52 2005
From: michal at harddata.com (Michal Jaegermann)
Date: Wed, 30 Mar 2005 10:17:52 -0700
Subject: mysql-server
In-Reply-To: <009701c53545$137b7240$7202a8c0@ccb2vpjza>;
	from ismanager@ccbnpts.com on Wed, Mar 30, 2005 at 10:25:24AM
	-0600
References: <2719.208.48.139.172.1112143445.squirrel@www.greenhydrant.com>
	<009701c53545$137b7240$7202a8c0@ccb2vpjza>
Message-ID: <20050330101752.C28662@mail.harddata.com>

On Wed, Mar 30, 2005 at 10:25:24AM -0600, Pettit, Paul wrote:
> > David Rees wrote:
> >  ... add the following to root's
> > crontab:
> > 
> > 0 7 * * 1,2,3,4,5 /etc/<somewhere>/yum.cron
> > 
> 
> Yeah that will work for now but dealing with holidays is a bit more
> tricky. Yum nor Crom really don't have any method for dealing with it

Sigh!  As it was sugested already you start your update script
with something of that sort

#!/bin/bash
.....
today=$(date +%Y%m%d)

while read banned comment; do
  [ "$today" = "$banned" ] && exit 0
done < /usr/local/share/my_no_update_day_list
.....
# now we are running yum or whatever else
....

and what you put on /usr/local/share/my_no_update_day_list is entirely
up to you and is really not possible for anybody else to know what
particular policies you may desire.

BTW - "1,2,3,4,5" above can be also written as "1-5" or "mon-fri" if
you prefer.  Once again - 'man 5 crontab'.

Can we stop all of that now?

   Michal



From ismanager at ccbnpts.com  Wed Mar 30 17:28:51 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Wed, 30 Mar 2005 11:28:51 -0600
Subject: mysql-server
In-Reply-To: <20050330101752.C28662@mail.harddata.com>
Message-ID: <00a301c5354d$f07d8900$7202a8c0@ccb2vpjza>

> Michal Jaegermann
> 
> On Wed, Mar 30, 2005 at 10:25:24AM -0600, Pettit, Paul wrote:
> > > David Rees wrote:
> > >  ... add the following to root's
> > > crontab:
> > > 
> > > 0 7 * * 1,2,3,4,5 /etc/<somewhere>/yum.cron
> > > 
> > 
> > Yeah that will work for now but dealing with holidays is a bit more
> > tricky. Yum nor Crom really don't have any method for 
> dealing with it
> 
> Sigh!  As it was sugested already you start your update script
> with something of that sort
> 

*sigh* Yes I know. 

> #!/bin/bash
> .....
> today=$(date +%Y%m%d)
> 
> while read banned comment; do
>   [ "$today" = "$banned" ] && exit 0
> done < /usr/local/share/my_no_update_day_list
> .....
> # now we are running yum or whatever else
> ....
> 
> and what you put on /usr/local/share/my_no_update_day_list is entirely
> up to you and is really not possible for anybody else to know what
> particular policies you may desire.
> 

That's a good addition. Thanks. 

> BTW - "1,2,3,4,5" above can be also written as "1-5" or "mon-fri" if
> you prefer.  Once again - 'man 5 crontab'.
> 

I didn't think it nessisary to take Dave to task on such a simple thing.

There is however a possible reason to leave it as '1,2,3,4,5'. That way
all you need to do is delete a single entry to blank out a day instead
of rewriting '1-5' into '1,2,4,5' (i.e. blanking out Wed) each time.
Meh, just a thought.

> Can we stop all of that now?
> 
>    Michal
> 

Stop all what? I think the discussion has run it's course actually.
Beyond a few comments here and there.

As for providing a script / documentation for admins to better control
updates from FL via Yum why would we stop that?

Paul Pettit



From paulp at ccbnpts.com  Wed Mar 30 18:22:30 2005
From: paulp at ccbnpts.com (Paul Pettit)
Date: Wed, 30 Mar 2005 12:22:30 -0600
Subject: Clearing the cache
Message-ID: <00b601c53555$6f2fe7f0$7202a8c0@ccb2vpjza>

I know that this is more a yum question but since I only use yum for FL
updates ...

How often should you clear the cache in yum? When is the best time
(before or after an update) to clear the cache? Server only uses yum for
FL updates (as stated above) so is it a big deal to just leave the files
there indefinately or should I set it to clean up often.

Thanks for any input.

Paul Pettit
CTO and IS Manager
Consistent Computer Bargains Inc.

I've heard it said that the proof of lunacy is when you repeat the same
steps expecting different results.  I say it's proof that you're a
Microsoft user. - comment by deshi777 on experts-exchange.com



From mattdm at mattdm.org  Wed Mar 30 18:48:31 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 30 Mar 2005 13:48:31 -0500
Subject: state of bugzilla (and, current kernel root exploits....)
In-Reply-To: <20050330094927.B28662@mail.harddata.com>
References: <20050329144737.GA17121@jadzia.bu.edu>
	<20050329193350.GK29340@urchin.earth.li>
	<20050330041340.GA16599@jadzia.bu.edu>
	<20050330094927.B28662@mail.harddata.com>
Message-ID: <20050330184831.GA9401@jadzia.bu.edu>

On Wed, Mar 30, 2005 at 09:49:27AM -0700, Michal Jaegermann wrote:
> > Done: <https://bugzilla.redhat.com/beta/show_bug.cgi?id=152532>
> By "Done" you mean that you managed to enter that report or that
> old data were imported? I tried to search for all Legacy bugs

Done as in "I did what was suggested, and entered the report." Sorry. Issue
is not done at all.

> I also wonder about "Version" field which is really a distribution
> tag.  It looks like that it can be set only to "core1", or "rhl9"
> or "rhl7.3" in an exclusive way.  If there is a bug which affects
> multiple distributions, which most often is the case although
> patch particulars may differ, then a bug report should be cloned
> across all these?  In particular #152532 clearly affects not
> only rhl9 but it is marked as such.

Yeah, this is a little bit of an issue. For tracking current state properly,
it's better to have separate bugs for each version -- they're not generated
from the same spec file, and they don't end up going to the same place, and
different distro versions will be affected differently.

This can feel a little bit like administrivia, but my experience with using
bugzilla to track the BU Linux project has convinced me that it's really
worth it and makes the whole process less error-prone.

The other downside, of course, is that it's kinda convenient to
"cross-pollinate" between development/QA for closely related issues. For our
own bugzilla-managed BU Linux project, we simply do that by making sure each
bug has a comment pointing to the bug # of the other one.

Another approach would be to add a version named "meta" or "tracking", and
create initial bugs like "CAN-005-468: rh9, fc1, fc2" and then create
individual bugs for each release and have them all block the top-level
tracking bug. This is even *more* administrative overhead, though.

I don't use RHL 7.x or FC1, so I only filed the RHL 9 one; I probably should
have filed the others as well. I can go ahead and do that, but I'll wait a
little bit to see what comes out of this discussion.

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>



From drees at greenhydrant.com  Wed Mar 30 19:25:00 2005
From: drees at greenhydrant.com (David Rees)
Date: Wed, 30 Mar 2005 11:25:00 -0800 (PST)
Subject: mysql-server
In-Reply-To: <00a001c53548$ba9aed00$7202a8c0@ccb2vpjza>
References: <1112195208.b768cfa1990cf@mail.ph.utexas.edu>
	<00a001c53548$ba9aed00$7202a8c0@ccb2vpjza>
Message-ID: <2092.208.48.139.172.1112210700.squirrel@www.greenhydrant.com>

On Wed, March 30, 2005 8:25 am, Pettit, Paul said:
>
> No, not much different than everyone else.
>
> I only possed an opinion (for which I have been thoroughly reamed for)
> in regards to timing the release of updates. My only mistake was not
> thinking of the problem on a more global scale in relation to timed
> releases. It's apparent that this must be done based on each persons
> local conditions. I had incorrectly thought it was something that FL
> might want to control or lend a hand dealing with.

On Wed, March 30, 2005 8:51 am, Pettit, Paul said:
>> Eric Rostetter
>> I think your opinion is worth the world.  And a lot of good ideas have
>> come from this discussion, some of which will help FL and its users
>> in the future.
>
> I can't see how anyone could believe you when you say "your opinion is
> worth the world". You've done nothing but attack me and my thoughts on
> the subject. I guess you value my opinion as it gives you ammo to shoot
> me with.

>From my point of view, the whole disagreement started when you (Paul)
started chastising the list (whether or not you meant for it to sound like
that) for not seeing things the way you saw them.

At which point people started getting defensive and annoyed (me included)
and the thread took on it's own life from there.

On Wed, March 30, 2005 8:25 am, Pettit, Paul said:
> Yes I did and it's the bet response of all the posts here. I thank you
> for actually trying to solve the problem, that's what a community is
> for. Saddly you're the only one that really did that. Tom had the same
> idea but (heh) did it in less useful terminology. :)

Just trying to solve a problem and get the flame-fest under control.  ;-)
I'm glad you finally found a good solution to your problem.

> Yeah that will work for now but dealing with holidays is a bit more
> tricky. Yum nor Crom really don't have any method for dealing with it
> and I'm not aware of another job scheduler for linux that would resolve
> the core issue.
>
> There in is the nut I need to crack. FL will be of no help in dealing
> with it and I can see why: tz issues, lack of ownership, no drive to
> resolve, and the mantra of security (updates out asap when "ready", not
> that that's bad).

This type of tone can easily set people off, even though the second
paragraph is true, it really does sound like an attack, whether you mean it
or not.  I would suggest leaving these types of comments off the list,
and instead keep posts focused on solutions (like you say below).

> I'll have to do some more programing and I'll try and send out the
> improved script (if I get it to work well) so others can use it. Did a
> test run but it took like 3 hours to run and I'm not sure why. :P

On Wed, March 30, 2005 8:51 am, Pettit, Paul said:
>
> It was never a battle in my mind (don't bother responding, you DO NOT
> know what I think) but an opinion that you took as an atttack on how FL
> runs.

It looked a battle to me on both ends.  I know I was frustrated.  Perhaps
we can all learn a lesson from this and think of the people on the other
side of the wire and keep the comments productive.

Cheers

Dave




From drees at greenhydrant.com  Wed Mar 30 19:25:54 2005
From: drees at greenhydrant.com (David Rees)
Date: Wed, 30 Mar 2005 11:25:54 -0800 (PST)
Subject: Clearing the cache
In-Reply-To: <00b601c53555$6f2fe7f0$7202a8c0@ccb2vpjza>
References: <00b601c53555$6f2fe7f0$7202a8c0@ccb2vpjza>
Message-ID: <2094.208.48.139.172.1112210754.squirrel@www.greenhydrant.com>

On Wed, March 30, 2005 10:22 am, Paul Pettit said:
> I know that this is more a yum question but since I only use yum for FL
> updates ...
>
> How often should you clear the cache in yum? When is the best time
> (before or after an update) to clear the cache? Server only uses yum for
> FL updates (as stated above) so is it a big deal to just leave the files
> there indefinately or should I set it to clean up often.

I clear the cache nightly in my yum cron script when there are no packages
to be updated.

-Dave



From ismanager at ccbnpts.com  Wed Mar 30 19:55:00 2005
From: ismanager at ccbnpts.com (Pettit, Paul)
Date: Wed, 30 Mar 2005 13:55:00 -0600
Subject: mysql-server
In-Reply-To: <2092.208.48.139.172.1112210700.squirrel@www.greenhydrant.com>
Message-ID: <00c601c53562$5b7441e0$7202a8c0@ccb2vpjza>

> David Rees wrote:
> 
> On Wed, March 30, 2005 8:25 am, Pettit, Paul said:
> >
> > No, not much different than everyone else.
> >
> > I only possed an opinion (for which I have been thoroughly 
> reamed for)
> > in regards to timing the release of updates. My only mistake was not
> > thinking of the problem on a more global scale in relation to timed
> > releases. It's apparent that this must be done based on each persons
> > local conditions. I had incorrectly thought it was something that FL
> > might want to control or lend a hand dealing with.
> 
> On Wed, March 30, 2005 8:51 am, Pettit, Paul said:
> >> Eric Rostetter
> >> I think your opinion is worth the world.  And a lot of 
> good ideas have
> >> come from this discussion, some of which will help FL and its users
> >> in the future.
> >
> > I can't see how anyone could believe you when you say "your 
> opinion is
> > worth the world". You've done nothing but attack me and my 
> thoughts on
> > the subject. I guess you value my opinion as it gives you 
> ammo to shoot
> > me with.
> 
> From my point of view, the whole disagreement started when you (Paul)
> started chastising the list (whether or not you meant for it 
> to sound like
> that) for not seeing things the way you saw them.
> 
> At which point people started getting defensive and annoyed 
> (me included)
> and the thread took on it's own life from there.
> 

I don't think that at anytime I chastized anyone except Eric, and that
because all he did was talk down to me.

If I gave that impression to anyone else on the list I humbily
apologize. 

It was my intent to express my opinion, not to change the world. I have
little power to do that unless we all agreee it'd be a good thing. My
opinion however was based on a narrow view of things and has since been
corrected.

> On Wed, March 30, 2005 8:25 am, Pettit, Paul said:
> > Yes I did and it's the bet response of all the posts here. 
> I thank you
> > for actually trying to solve the problem, that's what a community is
> > for. Saddly you're the only one that really did that. Tom 
> had the same
> > idea but (heh) did it in less useful terminology. :)
> 
> Just trying to solve a problem and get the flame-fest under 
> control.  ;-)
> I'm glad you finally found a good solution to your problem.
> 

Still working on it as you know. ;) 

> > Yeah that will work for now but dealing with holidays is a bit more
> > tricky. Yum nor Crom really don't have any method for 
> dealing with it
> > and I'm not aware of another job scheduler for linux that 
> would resolve
> > the core issue.
> >
> > There in is the nut I need to crack. FL will be of no help 
> in dealing
> > with it and I can see why: tz issues, lack of ownership, no drive to
> > resolve, and the mantra of security (updates out asap when 
> "ready", not
> > that that's bad).
> 
> This type of tone can easily set people off, even though the second
> paragraph is true, it really does sound like an attack, 
> whether you mean it
> or not.  I would suggest leaving these types of comments off the list,
> and instead keep posts focused on solutions (like you say below).
> 

See below ...

> > I'll have to do some more programing and I'll try and send out the
> > improved script (if I get it to work well) so others can 
> use it. Did a
> > test run but it took like 3 hours to run and I'm not sure why. :P
> 
> On Wed, March 30, 2005 8:51 am, Pettit, Paul said:
> >
> > It was never a battle in my mind (don't bother responding, 
> you DO NOT
> > know what I think) but an opinion that you took as an 
> atttack on how FL
> > runs.
> 
> It looked a battle to me on both ends.  I know I was 
> frustrated.  Perhaps
> we can all learn a lesson from this and think of the people 
> on the other
> side of the wire and keep the comments productive.
> 
> Cheers
> 
> Dave
> 

Just as a matter of point.

I rarely post to lists (any) because of what happened here. It's
probably all my fault as I like to speak in plain language and spell out
what I'm seeing. This often is taken as an attack when it's more of a
summary of my thoughts. It's a habit (bad?) which I see is not very
welcome here (heh) so I will try and control my urge to say more than is
absolutely needed for the problem at hand.

Peace.

Paul Pettit



From jkeating at j2solutions.net  Wed Mar 30 23:51:55 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 30 Mar 2005 15:51:55 -0800
Subject: STOP USING FEDORA.US BUGZILLA
Message-ID: <1112226715.3471.343.camel@jkeating2.hq.pogolinux.com>

Thats right folks, we have migrated all bug data from fedora.us to Red
Hat this afternoon.  Please do not use fedora.us anymore as any changes
will not be recorded.

All bugs have been moved over, but they have new numbers.  Please see
the Fedora Legacy component at Red Hat's bugzilla to find your bugs.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jkeating at j2solutions.net  Wed Mar 30 23:54:47 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 30 Mar 2005 15:54:47 -0800
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <4243813A.909@comcast.net>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<1111445092.28926.2.camel@mdlinux>
	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>
	<1111496949.14670.16.camel@mdlinux>
	<1111700039.3471.215.camel@jkeating2.hq.pogolinux.com>
	<4243813A.909@comcast.net>
Message-ID: <1112226887.3471.345.camel@jkeating2.hq.pogolinux.com>

On Thu, 2005-03-24 at 22:10 -0500, David Curry wrote:
> Discussion of the support horizon for FC releases has raised a
> question 
> or two.  FL continues to support RH 7.3 and RH9, but all discussion
> of 
> support for FC releases has focused on finite time horizons.  Is the 
> number of users wanting to stay with a particular release and help 
> support it a criterion that will be factored into the support
> horizon.  
> Or, will the FL support horizon for FC releases be strictly tied to
> Red 
> Hat's FC release calendar?

I'm taking the RH stance on this one.  The strict time line is a 'at
least this long' type of thing.  If there is significant interest in a
release and enough reason to do so, we can extend the life span.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jkeating at j2solutions.net  Wed Mar 30 23:56:56 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 30 Mar 2005 15:56:56 -0800
Subject: state of bugzilla (and, current kernel root exploits....)
In-Reply-To: <20050330094927.B28662@mail.harddata.com>
References: <20050329144737.GA17121@jadzia.bu.edu>
	<20050329193350.GK29340@urchin.earth.li>
	<20050330041340.GA16599@jadzia.bu.edu>
	<20050330094927.B28662@mail.harddata.com>
Message-ID: <1112227016.3471.347.camel@jkeating2.hq.pogolinux.com>

On Wed, 2005-03-30 at 09:49 -0700, Michal Jaegermann wrote:
> I also wonder about "Version" field which is really a distribution
> tag.  It looks like that it can be set only to "core1", or "rhl9"
> or "rhl7.3" in an exclusive way.  If there is a bug which affects
> multiple distributions, which most often is the case although
> patch particulars may differ, then a bug report should be cloned
> across all these?  In particular #152532 clearly affects not
> only rhl9 but it is marked as such.

There is an 'unspecified' version.  For now, for bugs that effect more
than one release, use this and then use the Status Whiteboard to insert
a keyword for the releases it effects, just like we did w/ keywords at
fedora.us.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From dsccable at comcast.net  Thu Mar 31 01:09:48 2005
From: dsccable at comcast.net (David Curry)
Date: Wed, 30 Mar 2005 20:09:48 -0500
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <1112226887.3471.345.camel@jkeating2.hq.pogolinux.com>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>	<423B6AAA.2020003@digitalhermit.com>	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>	<1111445092.28926.2.camel@mdlinux>	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>	<1111496949.14670.16.camel@mdlinux>	<1111700039.3471.215.camel@jkeating2.hq.pogolinux.com>	<4243813A.909@comcast.net>
	<1112226887.3471.345.camel@jkeating2.hq.pogolinux.com>
Message-ID: <424B4DDC.1020307@comcast.net>

Jesse Keating wrote:

>On Thu, 2005-03-24 at 22:10 -0500, David Curry wrote:
>  
>
>>Discussion of the support horizon for FC releases has raised a
>>question 
>>or two.  FL continues to support RH 7.3 and RH9, but all discussion
>>of 
>>support for FC releases has focused on finite time horizons.  Is the 
>>number of users wanting to stay with a particular release and help 
>>support it a criterion that will be factored into the support
>>horizon.  
>>Or, will the FL support horizon for FC releases be strictly tied to
>>Red 
>>Hat's FC release calendar?
>>    
>>
>
>I'm taking the RH stance on this one.  The strict time line is a 'at
>least this long' type of thing.  If there is significant interest in a
>release and enough reason to do so, we can extend the life span.
>
>  
>
Thanks, Jesse.



From jimpop at yahoo.com  Thu Mar 31 01:35:39 2005
From: jimpop at yahoo.com (Jim Popovitch)
Date: Wed, 30 Mar 2005 20:35:39 -0500
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <1112226887.3471.345.camel@jkeating2.hq.pogolinux.com>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<1111445092.28926.2.camel@mdlinux>
	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>
	<1111496949.14670.16.camel@mdlinux>
	<1111700039.3471.215.camel@jkeating2.hq.pogolinux.com>
	<4243813A.909@comcast.net>
	<1112226887.3471.345.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1112232939.10572.5.camel@blue>

On Wed, 2005-03-30 at 15:54 -0800, Jesse Keating wrote:

> I'm taking the RH stance on this one.  

What?  You going to alienate us too?  :-)

Seriously, saying your taking the RH stance still isn't really
considered too good these days.  I like RH, but what they did to
alienate their base users (I.E., not users who are paid by someone else
to use RH software) is still pretty unsettling in people's minds.
Still, for all that they did to piss people off, what else is there
really for enterprise strength, go home at five, software?

-Jim P.



From kleskoe at hotmail.com  Thu Mar 31 11:43:24 2005
From: kleskoe at hotmail.com (kles koe)
Date: Thu, 31 Mar 2005 11:43:24 +0000
Subject: rh7.3 filesystem becomes read only after update!?
Message-ID: <BAY21-F8E70AEEF6CA635839DFD1BF470@phx.gbl>

Hi folks,

last month i upgraded a rh7.3 server that has been running without problems 
for over 3 years or so with the the latest legacy kernel and all seemed well 
(i always apply the legacy updates after a few days).
yesterday i updated to the new sharutils package.

last night the server started giving me trouble.
seems i can't create files anymore!
i get messages like filesystem is read only.

eg:
# touch blah
touch: creating `blah': Read-only file system

however, mount gives me:
# mount
/dev/md2 on / type ext3 (rw)
none on /proc type proc (rw)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/md1 on /boot type ext3 (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /dev/shm type tmpfs (rw)

i noticed this problem because apache failed to restart:
# /usr/local/apache/bin/apachectl startssl
Ouch! ap_mm_create(1048576, "/usr/local/apache/logs/httpd.mm.11813") failed
Error: MM: mm:core: failed to open semaphore file (Read-only file system): 
OS: No such file or directory
/usr/local/apache/bin/apachectl startssl: httpd could not be started

- after the reboot for the kernel last month the server is still running 
(uptime 28 days now).
- the filesystem isn't full either.
- can't find anything in the log files that can give me a clue as to what 
could be wrong
- i have another 7.3 server that has been configured in practically the same 
way but doesnt have the sharutils package installed and that one has seems 
to be running just fine although the kernel was updated a few days later 
(uptime 23 days now).


nothing else happened on this system lately so i the only thing i can think 
of is that it has something to do with either the latest kernel or sharutils 
package...
does anybody else have this problem?

i have no clue as to where this problem comes from or how to resolve it.

i tried to remove the sharutils package alltogether but that doesnt work 
either:
# rpm -e sharutils
error: cannot get exclusive lock on /var/lib/rpm/Packages
error: cannot open Packages index using db3 - Operation not permitted (1)
error: cannot open /var/lib/rpm/packages.rpm


any ideas would be very welcome!

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/



From jeroen at easyhosting.nl  Thu Mar 31 11:57:03 2005
From: jeroen at easyhosting.nl (Jeroen Wunnink)
Date: Thu, 31 Mar 2005 13:57:03 +0200
Subject: rh7.3 filesystem becomes read only after update!?
In-Reply-To: <BAY21-F8E70AEEF6CA635839DFD1BF470@phx.gbl>
References: <BAY21-F8E70AEEF6CA635839DFD1BF470@phx.gbl>
Message-ID: <6.1.2.0.2.20050331135224.03b87670@mail.easyhosting.nl>

This usually means the filesystem jumps into read only mode because some fs 
errors have occured.
We've had this problem last month with a server, and it ended up that the 
harddisk was going bad.

You can try to remount the filesystem first: 'mount -o remount /home' for 
example and see if that solves it..

If not, you can try to unmount the filesystem directly if possible (make 
sure there's no processes keeping it occupied) and do a e2fsck on it, or 
reboot it in single user mode and then fsck all filesystems if it concerns 
/ or /boot for example..

It may solve it, but big chance that it'll pop back in read only mode after 
a while again..

Advice: back up the system and go swap the harddisk..


At 13:43 31-3-2005, you wrote:
>Hi folks,
>
>last month i upgraded a rh7.3 server that has been running without 
>problems for over 3 years or so with the the latest legacy kernel and all 
>seemed well (i always apply the legacy updates after a few days).
>yesterday i updated to the new sharutils package.
>
>last night the server started giving me trouble.
>seems i can't create files anymore!
>i get messages like filesystem is read only.
>
>eg:
># touch blah
>touch: creating `blah': Read-only file system
>
>however, mount gives me:
># mount
>/dev/md2 on / type ext3 (rw)
>none on /proc type proc (rw)
>usbdevfs on /proc/bus/usb type usbdevfs (rw)
>/dev/md1 on /boot type ext3 (rw)
>none on /dev/pts type devpts (rw,gid=5,mode=620)
>none on /dev/shm type tmpfs (rw)
>
>i noticed this problem because apache failed to restart:
># /usr/local/apache/bin/apachectl startssl
>Ouch! ap_mm_create(1048576, "/usr/local/apache/logs/httpd.mm.11813") failed
>Error: MM: mm:core: failed to open semaphore file (Read-only file system): 
>OS: No such file or directory
>/usr/local/apache/bin/apachectl startssl: httpd could not be started
>
>- after the reboot for the kernel last month the server is still running 
>(uptime 28 days now).
>- the filesystem isn't full either.
>- can't find anything in the log files that can give me a clue as to what 
>could be wrong
>- i have another 7.3 server that has been configured in practically the 
>same way but doesnt have the sharutils package installed and that one has 
>seems to be running just fine although the kernel was updated a few days 
>later (uptime 23 days now).
>
>
>nothing else happened on this system lately so i the only thing i can 
>think of is that it has something to do with either the latest kernel or 
>sharutils package...
>does anybody else have this problem?
>
>i have no clue as to where this problem comes from or how to resolve it.
>
>i tried to remove the sharutils package alltogether but that doesnt work 
>either:
># rpm -e sharutils
>error: cannot get exclusive lock on /var/lib/rpm/Packages
>error: cannot open Packages index using db3 - Operation not permitted (1)
>error: cannot open /var/lib/rpm/packages.rpm
>
>
>any ideas would be very welcome!
>
>_________________________________________________________________
>Don't just search. Find. Check out the new MSN Search! 
>http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
>--
>fedora-legacy-list mailing list
>fedora-legacy-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-legacy-list



Met vriendelijke groet,

Jeroen Wunnink,
EasyHosting B.V. Systeembeheerder
systeembeheer at easyhosting.nl

telefoon:+31 (035) 6285455              Postbus 48
fax: +31 (035) 6838242                  3755 ZG Eemnes

http://www.easyhosting.nl
http://www.easycolo.nl




From steffen.grunewald at aei.mpg.de  Thu Mar 31 12:31:46 2005
From: steffen.grunewald at aei.mpg.de (Steffen Grunewald)
Date: Thu, 31 Mar 2005 14:31:46 +0200
Subject: rh7.3 filesystem becomes read only after update!?
In-Reply-To: <6.1.2.0.2.20050331135224.03b87670@mail.easyhosting.nl>
References: <BAY21-F8E70AEEF6CA635839DFD1BF470@phx.gbl>
	<6.1.2.0.2.20050331135224.03b87670@mail.easyhosting.nl>
Message-ID: <20050331123146.GU12331@debian-server.aei.mpg.de>

On Thu, Mar 31, 2005 at 01:57:03PM +0200, Jeroen Wunnink wrote:
> This usually means the filesystem jumps into read only mode because some fs 
> errors have occured.
> We've had this problem last month with a server, and it ended up that the 
> harddisk was going bad.
> 
> You can try to remount the filesystem first: 'mount -o remount /home' for 
> example and see if that solves it..
> 
> If not, you can try to unmount the filesystem directly if possible (make 
> sure there's no processes keeping it occupied) and do a e2fsck on it, or 
> reboot it in single user mode and then fsck all filesystems if it concerns 
> / or /boot for example..
> 
> It may solve it, but big chance that it'll pop back in read only mode after 
> a while again..
> 
> Advice: back up the system and go swap the harddisk..

Additional advice: get the smartmontools package and run disk selftests
periodically. (smartmontools.sourceforge.net)

Cheers,
 Steffen

-- 
Steffen Grunewald * MPI fuer Gravitationsphysik (Albert-Einstein-Institut)
SciencePark Golm, Am M?hlenberg 1, D-14476 Potsdam * http://www.aei.mpg.de
* e-mail: steffen.grunewald(*)aei.mpg.de * +49-331-567-{fon:7233,fax:7298}
No Word/PPT mails - http://www.gnu.org/philosophy/no-word-attachments.html



From paulp at ccbnpts.com  Wed Mar 30 18:15:22 2005
From: paulp at ccbnpts.com (Paul Pettit)
Date: Wed, 30 Mar 2005 12:15:22 -0600
Subject: Clearing the cache
Message-ID: <00b301c53554$705830c0$7202a8c0@ccb2vpjza>

I know that this is more a yum question but since I only use yum for FL
updates ...

How often should you clear the cache in yum? When is the best time
(before or after an update) to clear the cache? Server only uses yum for
FL updates (as stated above) so is it a big deal to just leave the files
there indefinately or should I set it to clean up often.

Thanks for any input.

Paul Pettit
CTO and IS Manager
Consistent Computer Bargains Inc.

I've heard it said that the proof of lunacy is when you repeat the same
steps expecting different results.  I say it's proof that you're a
Microsoft user. - comment by deshi777 on experts-exchange.com



From dhiltz at whsun1.wh.whoi.edu  Thu Mar 31 13:52:24 2005
From: dhiltz at whsun1.wh.whoi.edu (David Hiltz)
Date: Thu, 31 Mar 2005 08:52:24 -0500
Subject: rh7.3 filesystem becomes read only after update!?
In-Reply-To: <20050331123146.GU12331@debian-server.aei.mpg.de>
References: <BAY21-F8E70AEEF6CA635839DFD1BF470@phx.gbl>	<6.1.2.0.2.20050331135224.03b87670@mail.easyhosting.nl>
	<20050331123146.GU12331@debian-server.aei.mpg.de>
Message-ID: <424C0098.9050905@whsun1.wh.whoi.edu>

An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050331/d3414539/attachment.htm>

From staf.verhaegen at skynet.be  Thu Mar 31 14:25:00 2005
From: staf.verhaegen at skynet.be (Staf Verhaegen)
Date: Thu, 31 Mar 2005 16:25:00 +0200
Subject: Problem with cups-1.1.14-15.4.4.legacy.i386.rpm on redhat 7.3
Message-ID: <1112279099.1839.13.camel@pc300>

I have an i386 computer here at home with redhat 7.3 on it. The machine
has a big history so rpm from everywhere are installed on there (ximian,
freshrpm, ATRpms, ...)
The rpm version is 4.3.3 from ATRpms (rpm-4.3.3-8_40.rh7.3.at).
The cups-libs package was upgraded to the latest version available from
Fedora Legacy (cups-libs-1.1.14-15.4.4.legacy). I can't install the
legacy package of cups itself though. First I had problems with smart
and yum but then I downloaded the cups rpm and tried to install it by
hand and that still failed:
% rpm --install cups-1.1.14-15.4.4.legacy.i386.rpm
error: Failed dependencies:
        cups-libs = 1.1.14 is needed by cups-1.1.14-15.4.4.legacy.i386

Is this a problem with the cups packages or with the version of rpm I am
using or is it something else still ?

greets,
Staf.




From hjp+fedora-legacy at wsr.ac.at  Thu Mar 31 14:43:33 2005
From: hjp+fedora-legacy at wsr.ac.at (Peter J. Holzer)
Date: Thu, 31 Mar 2005 16:43:33 +0200
Subject: rh7.3 filesystem becomes read only after update!?
In-Reply-To: <6.1.2.0.2.20050331135224.03b87670@mail.easyhosting.nl>
References: <BAY21-F8E70AEEF6CA635839DFD1BF470@phx.gbl>
	<6.1.2.0.2.20050331135224.03b87670@mail.easyhosting.nl>
Message-ID: <20050331144333.GG8131@wsr.ac.at>

On 2005-03-31 13:57:03 +0200, Jeroen Wunnink wrote:
> This usually means the filesystem jumps into read only mode because some fs 
> errors have occured.
> We've had this problem last month with a server, and it ended up that the 
> harddisk was going bad.
> 
> You can try to remount the filesystem first: 'mount -o remount /home' for 
> example and see if that solves it..

I wouldn't do this.  Ext2/3 goes into read-only mode only if it
discovers a serious inconsistency, so if you mount that filesystem rw
and then write some data to it, there is risk of further damaging it.

> If not, you can try to unmount the filesystem directly if possible (make 
> sure there's no processes keeping it occupied) and do a e2fsck on it, or 
> reboot it in single user mode and then fsck all filesystems if it concerns 
> / or /boot for example..

He has only / and /boot:

> >/dev/md2 on / type ext3 (rw)
> >/dev/md1 on /boot type ext3 (rw)

This also explains why there is nothing in the log files: After / was
remounted read-only syslogd couldn't write to /var/log/messages any
more.

> Advice: back up the system and go swap the harddisk..

He has RAID arrays, so he has to find out which hard disk to swap
first. (What kind of RAID arrays are these? A single disk going bad
shouldn't cause filesystem errors on RAID-1 or RAID-5)

1) Make a backup immediately (unless you already have
   one which is new enough). 

2) Reboot the server. It should check the filesystems and hopefully
   restore it to as useable state.

3) Check the harddisks. smartmontools have already been mentioned. 
   A simple "dd if=/dev/$disk of=/dev/null bs=64k" for all disks is also
   quite good at finding errors. 

4) If no harddisk errors have been found, try to find out what caused
   the filesystem corruption.


-- 
   _  | Peter J. Holzer \Beta means "we're down to fixing misspelled comments in
|_|_) | Sysadmin WSR     \the source, and you might run into a memory leak if 
| |   | hjp at wsr.ac.at     \you enable embedded haskell as a loadable module and
__/   | http://www.hjp.at/ \write your plugins upside-down in lisp". --ae at op5.se
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 388 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20050331/b67e54a2/attachment.sig>

From sweller at ena.com  Thu Mar 31 15:09:22 2005
From: sweller at ena.com (Simon Weller)
Date: Thu, 31 Mar 2005 09:09:22 -0600
Subject: rh7.3 filesystem becomes read only after update!?
In-Reply-To: <20050331144333.GG8131@wsr.ac.at>
References: <BAY21-F8E70AEEF6CA635839DFD1BF470@phx.gbl>
	<6.1.2.0.2.20050331135224.03b87670@mail.easyhosting.nl>
	<20050331144333.GG8131@wsr.ac.at>
Message-ID: <1112281762.27265.6.camel@misdc02.ena.com>

<snip>
> 
> 3) Check the harddisks. smartmontools have already been mentioned. 
>    A simple "dd if=/dev/$disk of=/dev/null bs=64k" for all disks is also
>    quite good at finding errors. 


> 4) If no harddisk errors have been found, try to find out what caused
>    the filesystem corruption.
> 
Smartmontools most likely won't work with Hardware RAID unless he's
using a 3ware controller, as the drive needs to have pass-through
ability.

Some other manufacturers have their own utilities (eg LSI's megamon)
that can retrieve SMART information from drives in an array, but other
than that RAID does make SMART more difficult.

- Si

-- 
Simon Weller 
Systems Engineer, LPIC-2
Education Networks of America
1101 McGavock St.
Nashville TN 37203
Phone:  615.312.6068



From cra at WPI.EDU  Thu Mar 31 15:17:06 2005
From: cra at WPI.EDU (Chuck R. Anderson)
Date: Thu, 31 Mar 2005 10:17:06 -0500
Subject: rh7.3 filesystem becomes read only after update!?
In-Reply-To: <1112281762.27265.6.camel@misdc02.ena.com>
References: <BAY21-F8E70AEEF6CA635839DFD1BF470@phx.gbl>
	<6.1.2.0.2.20050331135224.03b87670@mail.easyhosting.nl>
	<20050331144333.GG8131@wsr.ac.at>
	<1112281762.27265.6.camel@misdc02.ena.com>
Message-ID: <20050331151705.GC1738@angus.ind.WPI.EDU>

On Thu, Mar 31, 2005 at 09:09:22AM -0600, Simon Weller wrote:
> Smartmontools most likely won't work with Hardware RAID unless he's
> using a 3ware controller, as the drive needs to have pass-through
> ability.

/dev/mdN is software raid.



From sweller at ena.com  Thu Mar 31 15:18:23 2005
From: sweller at ena.com (Simon Weller)
Date: Thu, 31 Mar 2005 09:18:23 -0600
Subject: rh7.3 filesystem becomes read only after update!?
In-Reply-To: <20050331151705.GC1738@angus.ind.WPI.EDU>
References: <BAY21-F8E70AEEF6CA635839DFD1BF470@phx.gbl>
	<6.1.2.0.2.20050331135224.03b87670@mail.easyhosting.nl>
	<20050331144333.GG8131@wsr.ac.at>
	<1112281762.27265.6.camel@misdc02.ena.com>
	<20050331151705.GC1738@angus.ind.WPI.EDU>
Message-ID: <1112282303.27265.8.camel@misdc02.ena.com>

On Thu, 2005-03-31 at 10:17 -0500, Chuck R. Anderson wrote:
> On Thu, Mar 31, 2005 at 09:09:22AM -0600, Simon Weller wrote:
> > Smartmontools most likely won't work with Hardware RAID unless he's
> > using a 3ware controller, as the drive needs to have pass-through
> > ability.
> 
> /dev/mdN is software raid.

I missed the device names, you're right.

- Si
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
-- 
Simon Weller 
Systems Engineer, LPIC-2
Education Networks of America
1101 McGavock St.
Nashville TN 37203
Phone:  615.312.6068



From rdieter at math.unl.edu  Thu Mar 31 15:20:46 2005
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 31 Mar 2005 09:20:46 -0600
Subject: Problem with cups-1.1.14-15.4.4.legacy.i386.rpm on redhat 7.3
In-Reply-To: <1112279099.1839.13.camel@pc300>
References: <1112279099.1839.13.camel@pc300>
Message-ID: <d2h4eb$eq9$1@sea.gmane.org>

Staf Verhaegen wrote:
> First I had problems with smart
> and yum but then I downloaded the cups rpm and tried to install it by
> hand and that still failed:
> % rpm --install cups-1.1.14-15.4.4.legacy.i386.rpm
> error: Failed dependencies:
>         cups-libs = 1.1.14 is needed by cups-1.1.14-15.4.4.legacy.i386
> 
> Is this a problem with the cups packages or with the version of rpm I am
> using or is it something else still ?

The error message is quite clear... you need to *also* install/upgrade 
the cups-libs rpm.

Now, smart/yum *should* have done that for you automatically.  Perhaps 
you could post what errors smart/yum gave?

-- Rex



From kleskoe at hotmail.com  Thu Mar 31 15:45:47 2005
From: kleskoe at hotmail.com (kles koe)
Date: Thu, 31 Mar 2005 15:45:47 +0000
Subject: rh7.3 filesystem becomes read only after update!?
In-Reply-To: <6.1.2.0.2.20050331135224.03b87670@mail.easyhosting.nl>
Message-ID: <BAY21-F26B5CDB93C47C03674FDF1BF470@phx.gbl>

tnx a lot for your suggestions.

you seem to be right,
has probably nothing to do with the legacy updates after all
after some research i found out the entire raid array seems to be dying.
this just coincidentally happened right after an update.

im sorry if i upset ya'll.



>From: Jeroen Wunnink <jeroen at easyhosting.nl>
>Reply-To: Discussion of the Fedora Legacy Project 
><fedora-legacy-list at redhat.com>
>To: Discussion of the Fedora Legacy Project <fedora-legacy-list at redhat.com>
>Subject: Re: rh7.3 filesystem becomes read only after update!?
>Date: Thu, 31 Mar 2005 13:57:03 +0200
>
>This usually means the filesystem jumps into read only mode because some fs 
>errors have occured.
>We've had this problem last month with a server, and it ended up that the 
>harddisk was going bad.
>
>You can try to remount the filesystem first: 'mount -o remount /home' for 
>example and see if that solves it..
>
>If not, you can try to unmount the filesystem directly if possible (make 
>sure there's no processes keeping it occupied) and do a e2fsck on it, or 
>reboot it in single user mode and then fsck all filesystems if it concerns 
>/ or /boot for example..
>
>It may solve it, but big chance that it'll pop back in read only mode after 
>a while again..
>
>Advice: back up the system and go swap the harddisk..
>
>
>At 13:43 31-3-2005, you wrote:
>>Hi folks,
>>
>>last month i upgraded a rh7.3 server that has been running without 
>>problems for over 3 years or so with the the latest legacy kernel and all 
>>seemed well (i always apply the legacy updates after a few days).
>>yesterday i updated to the new sharutils package.
>>
>>last night the server started giving me trouble.
>>seems i can't create files anymore!
>>i get messages like filesystem is read only.
>>
>>eg:
>># touch blah
>>touch: creating `blah': Read-only file system
>>
>>however, mount gives me:
>># mount
>>/dev/md2 on / type ext3 (rw)
>>none on /proc type proc (rw)
>>usbdevfs on /proc/bus/usb type usbdevfs (rw)
>>/dev/md1 on /boot type ext3 (rw)
>>none on /dev/pts type devpts (rw,gid=5,mode=620)
>>none on /dev/shm type tmpfs (rw)
>>
>>i noticed this problem because apache failed to restart:
>># /usr/local/apache/bin/apachectl startssl
>>Ouch! ap_mm_create(1048576, "/usr/local/apache/logs/httpd.mm.11813") 
>>failed
>>Error: MM: mm:core: failed to open semaphore file (Read-only file system): 
>>OS: No such file or directory
>>/usr/local/apache/bin/apachectl startssl: httpd could not be started
>>
>>- after the reboot for the kernel last month the server is still running 
>>(uptime 28 days now).
>>- the filesystem isn't full either.
>>- can't find anything in the log files that can give me a clue as to what 
>>could be wrong
>>- i have another 7.3 server that has been configured in practically the 
>>same way but doesnt have the sharutils package installed and that one has 
>>seems to be running just fine although the kernel was updated a few days 
>>later (uptime 23 days now).
>>
>>
>>nothing else happened on this system lately so i the only thing i can 
>>think of is that it has something to do with either the latest kernel or 
>>sharutils package...
>>does anybody else have this problem?
>>
>>i have no clue as to where this problem comes from or how to resolve it.
>>
>>i tried to remove the sharutils package alltogether but that doesnt work 
>>either:
>># rpm -e sharutils
>>error: cannot get exclusive lock on /var/lib/rpm/Packages
>>error: cannot open Packages index using db3 - Operation not permitted (1)
>>error: cannot open /var/lib/rpm/packages.rpm
>>
>>
>>any ideas would be very welcome!
>>
>>_________________________________________________________________
>>Don't just search. Find. Check out the new MSN Search! 
>>http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>>
>>--
>>fedora-legacy-list mailing list
>>fedora-legacy-list at redhat.com
>>http://www.redhat.com/mailman/listinfo/fedora-legacy-list
>
>
>
>Met vriendelijke groet,
>
>Jeroen Wunnink,
>EasyHosting B.V. Systeembeheerder
>systeembeheer at easyhosting.nl
>
>telefoon:+31 (035) 6285455              Postbus 48
>fax: +31 (035) 6838242                  3755 ZG Eemnes
>
>http://www.easyhosting.nl
>http://www.easycolo.nl
>
>
>--
>fedora-legacy-list mailing list
>fedora-legacy-list at redhat.com
>http://www.redhat.com/mailman/listinfo/fedora-legacy-list

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/



From rostetter at mail.utexas.edu  Thu Mar 31 16:50:05 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Thu, 31 Mar 2005 10:50:05 -0600
Subject: wiki broken?
Message-ID: <1112287805.9e9b6e3ca9af8@mail.ph.utexas.edu>


The wiki appears to be broken.  I can see the indexes, but clicking on a 
page link returns something like:

lib/WikiDB/backend/PearDB.php:32: Fatal[256]: Can't connect to database:
wikidb_backend_mysql: fatal database error

    * DB Error: unknown error
    * ( [nativecode=Commands out of sync; You can't run this command now] **
mysql://legwik:XXXXXXXX at unix(/var/lib/mysql/mysql.sock)/legacywiki)

Would be ironic if the last mysql update killed it *Grin*

-- 
Eric Rostetter



From jkeating at j2solutions.net  Thu Mar 31 17:13:35 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 31 Mar 2005 09:13:35 -0800
Subject: FL update policy [Re: just one VERIFY to be fully published]
In-Reply-To: <1112232939.10572.5.camel@blue>
References: <Pine.LNX.4.61.0503182136280.26820@netcore.fi>
	<423B6AAA.2020003@digitalhermit.com>
	<Pine.LNX.4.61.0503211551250.16101@netcore.fi>
	<1111445092.28926.2.camel@mdlinux>
	<Pine.LNX.4.61.0503220844250.2950@netcore.fi>
	<1111496949.14670.16.camel@mdlinux>
	<1111700039.3471.215.camel@jkeating2.hq.pogolinux.com>
	<4243813A.909@comcast.net>
	<1112226887.3471.345.camel@jkeating2.hq.pogolinux.com>
	<1112232939.10572.5.camel@blue>
Message-ID: <1112289215.3471.356.camel@jkeating2.hq.pogolinux.com>

On Wed, 2005-03-30 at 20:35 -0500, Jim Popovitch wrote:
> What?  You going to alienate us too?  :-)
> 
> Seriously, saying your taking the RH stance still isn't really
> considered too good these days.  I like RH, but what they did to
> alienate their base users (I.E., not users who are paid by someone
> else
> to use RH software) is still pretty unsettling in people's minds.
> Still, for all that they did to piss people off, what else is there
> really for enterprise strength, go home at five, software?

*sigh* not to really start a war, but I still laugh at this.  I for one
do not feel alienated whatsoever.  Of course, I also don't subscribe to
most fud that people spread around the time of transition from Red Hat
Linux to Red Hat Linux Project to Fedora Project.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jkeating at j2solutions.net  Thu Mar 31 17:14:34 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 31 Mar 2005 09:14:34 -0800
Subject: Mirroring: Bad datestamps prevent hardlinking
In-Reply-To: <20050326223150.GB5752@neu.nirvana>
References: <20050326223150.GB5752@neu.nirvana>
Message-ID: <1112289274.3471.358.camel@jkeating2.hq.pogolinux.com>

On Sat, 2005-03-26 at 23:31 +0100, Axel Thimm wrote:
> Could the parts that are mirrored from Red Hat be timestamped back to
> their original values? For instance:
> 
> 58217 Oct 29  2003
> download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/ncompress-4.2.4-34.src.rpm
> 58217 Feb 27  2004
> download.fedoralegacy.org/fedora/1/os/SRPMS/ncompress-4.2.4-34.src.rpm
> 
> This would allow mirrors of both RH and FL to run hardlink over the
> folders and rescue some bits.

Got a good suggestion on how to do that w/out re-downloading every file
from RH mirrors?

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jkeating at j2solutions.net  Thu Mar 31 17:17:46 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 31 Mar 2005 09:17:46 -0800
Subject: wiki broken?
In-Reply-To: <1112287805.9e9b6e3ca9af8@mail.ph.utexas.edu>
References: <1112287805.9e9b6e3ca9af8@mail.ph.utexas.edu>
Message-ID: <1112289466.3471.361.camel@jkeating2.hq.pogolinux.com>

On Thu, 2005-03-31 at 10:50 -0600, Eric Rostetter wrote:
> 
> The wiki appears to be broken.  I can see the indexes, but clicking on
> a 
> page link returns something like:
> 
> lib/WikiDB/backend/PearDB.php:32: Fatal[256]: Can't connect to
> database:
> wikidb_backend_mysql: fatal database error
> 
>     * DB Error: unknown error
>     * ( [nativecode=Commands out of sync; You can't run this command
> now] **
> mysql://legwik:XXXXXXXX at unix(/var/lib/mysql/mysql.sock)/legacywiki)
> 
> Would be ironic if the last mysql update killed it *Grin*

No, that was me that killed it.  I had some issues on that server, dspam
was being used for spam filtering and had driven the load up to oh 80 or
so.  Corrupted its database files (which had grown to 800 megs or so in
size) so I had shut mysql down while I attempted to repair the db.
Eventually I killed off dspam and migrated to Spamassassin but I think I
needed to restart a few more things to get the wiki back in action.

On another note, I'm going to pursue the idea of using
fedoraproject.org's wiki space for Fedora Legacy.  Seems like a good
thing to do.  Any thoughts?

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From michal at harddata.com  Thu Mar 31 17:30:48 2005
From: michal at harddata.com (Michal Jaegermann)
Date: Thu, 31 Mar 2005 10:30:48 -0700
Subject: rh7.3 filesystem becomes read only after update!?
In-Reply-To: <BAY21-F8E70AEEF6CA635839DFD1BF470@phx.gbl>;
	from kleskoe@hotmail.com on Thu, Mar 31, 2005 at 11:43:24AM +0000
References: <BAY21-F8E70AEEF6CA635839DFD1BF470@phx.gbl>
Message-ID: <20050331103048.B401@mail.harddata.com>

On Thu, Mar 31, 2005 at 11:43:24AM +0000, kles koe wrote:
> 
> however, mount gives me:
> # mount

'mount' reports what it sees in /etc/mtab and this file was not
updated if this file system:

> /dev/md2 on / type ext3 (rw)

is failing and got remounted ro.  'cat /proc/mounts' will show what
kernel thinks about that.  These two pictures are usually close but
not the same.

BTW - if /etc/mtab is writable you can manipulate it content, hence
also what 'mount' reports, using -f option to 'mount'.  This is
often done in a startup.

   Michal



From gbailey at lxpro.com  Thu Mar 31 17:27:18 2005
From: gbailey at lxpro.com (Greg Bailey)
Date: Thu, 31 Mar 2005 10:27:18 -0700
Subject: Mirroring: Bad datestamps prevent hardlinking
In-Reply-To: <1112289274.3471.358.camel@jkeating2.hq.pogolinux.com>
References: <20050326223150.GB5752@neu.nirvana>
	<1112289274.3471.358.camel@jkeating2.hq.pogolinux.com>
Message-ID: <424C32F6.20409@lxpro.com>

Jesse Keating wrote:

>On Sat, 2005-03-26 at 23:31 +0100, Axel Thimm wrote:
>  
>
>>Could the parts that are mirrored from Red Hat be timestamped back to
>>their original values? For instance:
>>
>>58217 Oct 29  2003
>>download.fedora.redhat.com/pub/fedora/linux/core/1/SRPMS/ncompress-4.2.4-34.src.rpm
>>58217 Feb 27  2004
>>download.fedoralegacy.org/fedora/1/os/SRPMS/ncompress-4.2.4-34.src.rpm
>>
>>This would allow mirrors of both RH and FL to run hardlink over the
>>folders and rescue some bits.
>>    
>>
>
>Got a good suggestion on how to do that w/out re-downloading every file
>from RH mirrors?
>
>  
>
Wouldn't running rsync over the mirrored parts go fairly quickly if you 
already have the full fileset?  I recall doing this sort of thing when I 
was a RedHat mirror admin in a former life.  It didn't take long at all 
with the speedup rsync provides.

-Greg Bailey



From rostetter at mail.utexas.edu  Thu Mar 31 18:27:45 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Thu, 31 Mar 2005 12:27:45 -0600
Subject: wiki broken?
In-Reply-To: <1112289466.3471.361.camel@jkeating2.hq.pogolinux.com>
References: <1112287805.9e9b6e3ca9af8@mail.ph.utexas.edu>
	<1112289466.3471.361.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1112293665.79480f26132e0@mail.ph.utexas.edu>

Quoting Jesse Keating <jkeating at j2solutions.net>:

> On another note, I'm going to pursue the idea of using
> fedoraproject.org's wiki space for Fedora Legacy.  Seems like a good
> thing to do.  Any thoughts?

Can you give us the reasons it seems like a good idea to you?  If I know
why you want to do it, then maybe I'd agree with you.

I'd also want more details about the actual implementation before I commented
on it.  Would it be a separate "virtual" wiki?  Or a tree in their wiki?
What would the url be? etc.

-- 
Eric Rostetter



From jkeating at j2solutions.net  Thu Mar 31 18:37:32 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 31 Mar 2005 10:37:32 -0800
Subject: wiki broken?
In-Reply-To: <1112293665.79480f26132e0@mail.ph.utexas.edu>
References: <1112287805.9e9b6e3ca9af8@mail.ph.utexas.edu>
	<1112289466.3471.361.camel@jkeating2.hq.pogolinux.com>
	<1112293665.79480f26132e0@mail.ph.utexas.edu>
Message-ID: <1112294252.3471.378.camel@jkeating2.hq.pogolinux.com>

On Thu, 2005-03-31 at 12:27 -0600, Eric Rostetter wrote:
> Can you give us the reasons it seems like a good idea to you?  If I
> know
> why you want to do it, then maybe I'd agree with you.

Fedora Project website is a central place for Fedora stuff, and Legacy
is a fedora stuff.  The hardware will be better maintained and software
has more people looking after it.  It is already setup for user auth, so
random spamming will be less of an issue.

Also, docs we come up with, and docs other groups come up with can be
linked and reused within the same system making collaboration a bit
easier.

> I'd also want more details about the actual implementation before I
> commented
> on it.  Would it be a separate "virtual" wiki?  Or a tree in their
> wiki?
> What would the url be? etc.

We're working on these details right now.  I would like to include you
on the email conversations I have regarding this.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From rostetter at mail.utexas.edu  Thu Mar 31 18:43:00 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Thu, 31 Mar 2005 12:43:00 -0600
Subject: wiki broken?
In-Reply-To: <1112294252.3471.378.camel@jkeating2.hq.pogolinux.com>
References: <1112287805.9e9b6e3ca9af8@mail.ph.utexas.edu>
	<1112289466.3471.361.camel@jkeating2.hq.pogolinux.com>
	<1112293665.79480f26132e0@mail.ph.utexas.edu>
	<1112294252.3471.378.camel@jkeating2.hq.pogolinux.com>
Message-ID: <1112294580.cb3de5b4958cd@mail.ph.utexas.edu>

Quoting Jesse Keating <jkeating at j2solutions.net>:

> On Thu, 2005-03-31 at 12:27 -0600, Eric Rostetter wrote:
> > Can you give us the reasons it seems like a good idea to you?  If I
> > know
> > why you want to do it, then maybe I'd agree with you.
> 
> Fedora Project website is a central place for Fedora stuff, and Legacy
> is a fedora stuff.

Weak argument, but I can accept it.

> The hardware will be better maintained and software
> has more people looking after it.  It is already setup for user auth, so
> random spamming will be less of an issue.

This sounds like a win.
 
> Also, docs we come up with, and docs other groups come up with can be
> linked and reused within the same system making collaboration a bit
> easier.

A big win.

> > I'd also want more details about the actual implementation before I
> > commented
> > on it.  Would it be a separate "virtual" wiki?  Or a tree in their
> > wiki?
> > What would the url be? etc.
> 
> We're working on these details right now.

As long as the url to the FL wiki stuff is easy to remember, then I'm on board.
I'd give this a qualified yes vote.

>  I would like to include you
> on the email conversations I have regarding this.

Fine.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Thu Mar 31 18:47:36 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Thu, 31 Mar 2005 12:47:36 -0600
Subject: Problem with cups-1.1.14-15.4.4.legacy.i386.rpm on redhat 7.3
In-Reply-To: <1112279099.1839.13.camel@pc300>
References: <1112279099.1839.13.camel@pc300>
Message-ID: <1112294856.6f2752f4465d7@mail.ph.utexas.edu>

Quoting Staf Verhaegen <staf.verhaegen at skynet.be>:

> % rpm --install cups-1.1.14-15.4.4.legacy.i386.rpm
> error: Failed dependencies:
>         cups-libs = 1.1.14 is needed by cups-1.1.14-15.4.4.legacy.i386

You need to do an "upgrade" instead of an install.  Try

rpm -U cups-1.1.14-15.4.4.legacy.i386.rpm
 
> Is this a problem with the cups packages or with the version of rpm I am
> using or is it something else still ?

I *think* it is your command line.  Try update instead of install, and see
if that doesn't fix your problem.

> 
> greets,
> Staf.

-- 
Eric Rostetter



From rostetter at mail.utexas.edu  Thu Mar 31 21:19:18 2005
From: rostetter at mail.utexas.edu (Eric Rostetter)
Date: Thu, 31 Mar 2005 15:19:18 -0600
Subject: mysql-server
In-Reply-To: <009701c53545$137b7240$7202a8c0@ccb2vpjza>
References: <009701c53545$137b7240$7202a8c0@ccb2vpjza>
Message-ID: <1112303958.c220b493ddc97@mail.ph.utexas.edu>

Quoting "Pettit, Paul" <ismanager at ccbnpts.com>:

> The documentation however will need to be changed. I'm working on that
> and will try and edit it once I figure out wiki (never used it before).

Since the wiki is down, I created a doc at

http://www.fedoralegacy.org/docs/autoupdates.php

as a starting point to addressing these issues.  Comments, feedback, better
docs, changes, etc. all welcome.

If we get a concenses that the doc is good, I'll link it into all the other
docs that reference yum auto-updates.

-- 
Eric Rostetter



From eric.rostetter at physics.utexas.edu  Thu Mar 31 23:30:57 2005
From: eric.rostetter at physics.utexas.edu (Eric Rostetter)
Date: Thu, 31 Mar 2005 17:30:57 -0600
Subject: mysql-server
In-Reply-To: <1112195208.b768cfa1990cf@mail.ph.utexas.edu>
References: <009501c5349e$2eaf6190$7202a8c0@ccb2vpjza>
	<1112195208.b768cfa1990cf@mail.ph.utexas.edu>
Message-ID: <1112311857.2f628bc7848bb@mail.ph.utexas.edu>


For anyone who wants to further study the issue of "best practices" for
update managment, the following Microsoft (of all things) link may be of
interest.  While it is specific to Microsoft Windows, the basic concepts
all apply to linux.  The basic premise is: don't do automatic updates
on production servers, don't blindly install every update that comes out,
and have a plan that you follow for doing updates.  The link is:

http://www.microsoft.com/technet/security/bestprac/bpsp.mspx

Another doc that may be of interest as well is:

www.cressida.info/pdfs/whitepapers/bestpractices.pdf

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin
 
Why get even? Get odd!