Difference between revisions of "Updates cycles"

OVERVIEW

The SME Server update and maintenance cycle consists of the management of a number of repositories and package categories.

Repositories

The master directories associated with the update and maintenance cycles are located on the build system. Their content is then propagated to the mirrors.

They are:

dev [corresponds to smedev in the mirrors]
test [corresponds to smetest in the mirrors]
updates-testing [corresponds to smeupdates-testing in the mirrors]
updates [corresponds to smeupdates in the mirrors]

In addition, there is a staging area (stage) that is used to build the next ISO, you will see reference to it in some repository update emails.

Package Categories

Sme modified packages.

Changelog generated in-house and includes a reference to a Bug in Bugzilla. Verification required before release.

Upstream packages

i.e. packages from centos, epel, atrpms, rpmforge, etc). These are either not SME modified packages, or are kernel mods. There are no bug reports or in-house changelog generated, summary testing only before release.

Clamav packages.

This is a special case. Whilst not build by SME, and due to problem having been experienced in the past, these packages (three of them) are attached to a single SME bug in bugzilla. There is no specific changelog, however verification is recommended before release.

Contribs.

Not part of the updatesteam maintenance cycle. Verification and release are managed by individual maintainers, however contribs packages are created in smetest, then moved direct to smecontribs - they do not appear in smeupdates-testing.

BUILD SYSTEM

The build system generates automatically all categories of packages by means of a script developed by Shad Lords. The script looks for all packages in higher level repos (contribs, updates, os, extras, etc) and checks for newer version in centos, epel, atrpms, rpmforge, buildsys. If it finds a newer version then it will automatically move it to the smetest repo. This is where developers/contributors should look for possible updates. No checking has been done at this point and quiet often the packages pulled automatically aren't fully compatible.

In most instances, the script will see newly built packages and put them in smetest automatically. All transaction are the subject of a repository update email (from releases@contribs.org) to the updatesteam list. For example, as soon as a new tzdata package from centos becomes available for sme8, the new package is dropped into smetest.

An automated email is also generated:

Subject:[updatesteam] Repository Update
Date: 	Mon, 26 Nov 2012 10:47:31 -0700
From: 	releases@contribs.org (Releases)
To: 	updatesteam@lists.contribs.org

tzdata (sme8)

copy from centos to smetest (tzdata-2012i-2.el5.i386.rpm)
copy from centos to smetest (tzdata-2012i-2.el5.src.rpm)
copy from centos to smetest (tzdata-2012i-2.el5.x86_64.rpm)

rebuild repo (sme8)

rebuild smetest/i386
rebuild smetest/x86_64
_______________________________________________
SME Server maintenance team internal discussion
To unsubscribe, e-mail updatesteam-unsubscribe@lists.contribs.org
Searchable archive at http://lists.contribs.org/mailman/private/updatesteam/

However, if the build system has never seen a package before, the package will end up in smedev instead of smetest. Smedev is where all first time built packages end up. It is also where all the extra packages that come out of a build end up if we don't use them. An example is php. We don't use all the packages that come out of the php srpm. The ones we don't use end up in smedev while the rest that we do would progress from smetest -> smeupdates-testing -> smeupdates -> smeos. Smetest and smedev are basically on the same level but are separate so the developers don't have to sift through all the unwanted/unneeded packages. If a package becomes wanted or needed then move it from smedev to smetest.

All packages we know about are checked. If a developer adds a new dependency that we haven't seen before, then the developer will need to manually scp the file into smetest on first use for it to be processed and added to the distro. After that the script will check for newer/updated versions and drop them automatically in smetest whenever a new version is available. To build a package (the buildsys will choose itself where it goes) simply send the build command from your environement (see the wiki page for package build SME Server:Documentation:Developers Manual:Section3).

Each repository has a max number of versions and releases that it can contain. Most by default are set to 1 for both values. The exceptions are smetest that has versions = 2 and release = 3 and smeupdates-testing which has version = 1 and release = 3. It means that the test repo can have two different version streams (devel and prod) as well as several releases on each version.

When the developer is satisfied that a package won't break the system and wants wider testing without actually releasing things, the package should be moved manually into smeupdates-testing. This is a semi-stable testing area that shouldn't break a system but hasn't been verified yet. This repo is also included in Shad's staging area (stage) for the purpose of building the next ISO. All verifications should be done on packages in smeupdates-testing. Once the package is verified, and agreement reached on the Go/NoGo for releasing, the package should be copied manually to smeupdates and released.

MOVING PACKAGES FROM ONE REPO TO ANOTHER

The update cycle involves moving packages manually from:

smedev to smetest (infrequent)
smetest to smeupdates-testing
smeupdates-testing to smeudates

Packages can be moved (mv) or copied (cp). For all intent and purposes, only the copy command (cp) is required. These operations are supervised by an automated update script. This script runs every two hours and checks all repositories and tries to do the right thing as far as moving packages around and cleaning up where packages came from. The automated scripts will take care of ensuring all the right actions (eg multiple RPMs, SRPM, removal of older versions) are taken for a particular package, look at the repository update emails (emails from releases@contribs.org) to the updatesteam list to see how it flows. For multiple RPMs (eg clamav) it is only needed to move one RPM, and then the whole family of RPMs and the SRPM moves. Also the scripts ensure that there is always at least one SRPM associated with a family of RPMs (noting that multiple packages can be built from one rpm spec file/tarball/src.rpm).

So how to move packages? As an example, lets take a clamav set of three RPMS available for version 7. As soon as available, the build system automated script will drop them in smetest.

Lets move them to smeupdates-testing for verification and future release:

SSH into shell.contribs.org
Copy the package:

$ cd /teams/smeserver/7
$ cp test/clamav-0.97.6-1.el4.rf.i386.rpm updates-testing/

Within two hours max, the automated scripts will move this package AND all other relevant packages, so just pick any one of the three clamav RPMs and let Shad’s magic take care of the real moving. The script will also delete older packages, as applicable. Note that Shad's staging area (stage) used to build the next ISO is also refreshed automatically.

An automated email is also generated:

Subject: [updatesteam] Repository Update
Date: 	Tue, 20 Nov 2012 22:47:43 -0700
From: 	releases@contribs.org (Releases)
To: 	updatesteam@lists.contribs.org

clamav (sme7)
=============
delete from smeupdates-testing (i386, clamav-0.97.5-2.el4.rf.i386.rpm)
delete from stage (i386, clamav-0.97.5-2.el4.rf.i386.rpm)
delete from smeupdates-testing (x86_64, clamav-0.97.5-2.el4.rf.x86_64.rpm)
delete from stage (x86_64, clamav-0.97.5-2.el4.rf.x86_64.rpm)
delete from smeupdates-testing (SRPMS, clamav-0.97.5-2.rf.src.rpm)
delete from stage (SRPMS, clamav-0.97.5-2.rf.src.rpm)
copy from smeupdates-testing to stage (clamav-0.97.6-1.el4.rf.i386.rpm)
delete from smetest (i386, clamav-0.97.6-1.el4.rf.i386.rpm)
move from smetest to smeupdates-testing (clamav-0.97.6-1.el4.rf.x86_64.rpm)
copy from smeupdates-testing to stage (clamav-0.97.6-1.el4.rf.x86_64.rpm)
move from smetest to smeupdates-testing (clamav-0.97.6-1.rf.src.rpm)
copy from smeupdates-testing to stage (clamav-0.97.6-1.rf.src.rpm)
delete from smeupdates-testing (i386, clamav-db-0.97.5-2.el4.rf.i386.rpm)
delete from stage (i386, clamav-db-0.97.5-2.el4.rf.i386.rpm)
delete from smeupdates-testing (x86_64, clamav-db-0.97.5-2.el4.rf.x86_64.rpm)
delete from stage (x86_64, clamav-db-0.97.5-2.el4.rf.x86_64.rpm)
move from smetest to smeupdates-testing (clamav-db-0.97.6-1.el4.rf.i386.rpm)
copy from smeupdates-testing to stage (clamav-db-0.97.6-1.el4.rf.i386.rpm)
move from smetest to smeupdates-testing (clamav-db-0.97.6-1.el4.rf.x86_64.rpm)
copy from smeupdates-testing to stage (clamav-db-0.97.6-1.el4.rf.x86_64.rpm)
delete from smeupdates-testing (i386, clamd-0.97.5-2.el4.rf.i386.rpm)
delete from stage (i386, clamd-0.97.5-2.el4.rf.i386.rpm)
delete from smeupdates-testing (x86_64, clamd-0.97.5-2.el4.rf.x86_64.rpm)
delete from stage (x86_64, clamd-0.97.5-2.el4.rf.x86_64.rpm)
move from smetest to smeupdates-testing (clamd-0.97.6-1.el4.rf.i386.rpm)
copy from smeupdates-testing to stage (clamd-0.97.6-1.el4.rf.i386.rpm)
move from smetest to smeupdates-testing (clamd-0.97.6-1.el4.rf.x86_64.rpm)
copy from smeupdates-testing to stage (clamd-0.97.6-1.el4.rf.x86_64.rpm)

rebuild repo (sme7)
===================
rebuild smeupdates-testing/i386
rebuild smeupdates-testing/x86_64
rebuild smetest/i386
rebuild smetest/x86_64

VERIFICATION

A package should be verified using the standard verification template on a clean system, check SME Server:Documentation:QA:Verification for guidelines. The verification phase should also check for hard/soft dependencies which could break an update, and check for correct changelogs, including a reference to a bug number in bugzilla.

RELEASING UPDATES

Once verification is completed, it is customary to flag an impending release and seek comments using the updatesteam@lists.contribs.org. There may also be a need to deal with dependencies.

The final step after any comments and package dependencies have been addressed consists in the actual release. To release a package, just copy it into the updates directory on the build system.

As an example:

SSH into shell.contribs.org
Copy the package:

$ cd /teams/smeserver/7
$ cp updates-testing/clamav-0.97.6-1.el4.rf.i386.rpm updates/

The automated script will move all related packages and delete older packages, as applicable. An automated email is also generated:

Subject:[updatesteam] Repository Update
Date: 	Wed, 21 Nov 2012 16:47:46 -0700
From: 	releases@contribs.org (Releases)
To: 	updatesteam@lists.contribs.org

clamav (sme7)
=============
delete from smeupdates-testing (i386, clamav-0.97.6-1.el4.rf.i386.rpm)
move from smeupdates-testing to smeupdates (clamav-0.97.6-1.el4.rf.x86_64.rpm)
move from smeupdates-testing to smeupdates (clamav-0.97.6-1.rf.src.rpm)
delete from smeupdates-testing (i386, clamav-db-0.97.6-1.el4.rf.i386.rpm)
move from smeupdates-testing to smeupdates (clamav-db-0.97.6-1.el4.rf.x86_64.rpm)
delete from smeupdates-testing (i386, clamd-0.97.6-1.el4.rf.i386.rpm)
move from smeupdates-testing to smeupdates (clamd-0.97.6-1.el4.rf.x86_64.rpm)

rebuild repo (sme7)
===================
rebuild smeupdates/i386
rebuild smeupdates/x86_64
rebuild smeupdates-testing/i386
rebuild smeupdates-testing/x86_64

The final steps after release consist of:

a) Issuing a release note.

b) Updating the forums, this is optional except when releasing a new version number.

c) Closing all bugs associated with released packages.

DEALING WITH PACKAGE DEPENDENCIES.

This topic is incomplete and requires additional information

The verification phase taking place before release should pick up hard dependencies which could break an update. To the best of my understanding, the 'Verified Package Versions' tab in Rnotes will track hard dependencies - it does what Ian Wells used to do normally and try to build a bug and package dependency graph To be confirmed.

What needs to be checked manually is where a package fixes three bugs and one was not verified, the so-called soft dependencies. It means that only an older version of that package can be released. Also it can affect other packages if one of the fixes involved multiple packages. To be confirmed

The difference between "hard" and "soft" dependencies referred to in this document are:

a) Hard dependencies are those from the spec file, eg: requires: e-smith-lib >= 2.0.0-2

Developers put these in when it is necessary to enforce dependencies between packages.

b) Soft dependencies relates to .... needs a definition

As an illustration of soft deps, consider the following scenario, actual bug numbers etc are made up for this example:

e-smith-base 5.0.0-16
XXX 5.0.0-16.sme VERIFIED
- some text some text some text [SME: 6262]
XXX 5.0.0-15.sme RESOLVED
- some text some text some text [SME: 6248]
XXX 5.0.0-14.sme VERIFIED
- some text some text some text [SME: 6104]

e-smith-pop3 2.0.0-2
XXX 2.0.0-2.sme VERIFIED
- some text some text some text [SME: 6262]
XXX 2.0.0-1.sme VERIFIED
- some text some text some text [SME: 4633]

e-smith-apache 2.0.0-7
XXX 2.0.0-7.sme VERIFIED
- some text some text some text [SME: 6769]
XXX 2.0.0-6.sme VERIFIED
- some text some text some text [SME: 4633]

There are three modified packages, only bug 6248 has not yet been verified.

e-smith-base 5.0.0-16 cannot be released as it has a change that has not been verified.
- It would be possible to release e-smith-base 5.0.0-14
e-smith-pop3 2.0.0-2 cannot be released as e-smith-base 5.0.0-16 which contains part of the fix for bug 6262 is not being released.
e-smith-apache 2.0.0-7 cannot be released as part of the fix for Bug 4633 is in e-smith-pop3 2.0.0-1 which is not being released.

If you carefully check the code changes it may be possible to release e-smith-pop3 and e-smith-apache in the example above, but safest not to do so.

Note: Shad's automated script doesn't do any blocking of packages. It just tries to sort out where packages should belong based on where things exist when it starts running.

Last, we need to explain how dependencies setup between bugs in Bugzilla operate, and how they relates to hard/soft package dependencies if applicable.

ISSUE RELEASE NOTES

Wait for the mirrors to sync, and then email manually the release notes.

Example of release notes:

Subject:[updatesannounce] SME Server 7 Update: clamav-0.97.6-1
Date: 	Wed, 21 Nov 2012 23:24:53 -0800
From: 	Ian Wells <esmith@wellsi.com>
To: 	updatesannounce@contribs.org

--------------------------------------------------------------------------------
SME Server Update Notification
2012-11-21
--------------------------------------------------------------------------------

Name        : clamav
Product     : SME 7
Version     : 0.97.6
Release     : 1.el4.rf
URL         : [1]
Summary     : Anti-virus software
Description :
Clam AntiVirus is a GPL anti-virus toolkit for UNIX. The main purpose of
this software is the integration with mail servers (attachment scanning).
The package provides a flexible and scalable multi-threaded daemon, a
command line scanner, and a tool for automatic updating via Internet.

The programs are based on a shared library distributed with the Clam
AntiVirus package, which you can use with your own software. Most
importantly, the virus database is kept up to date
--------------------------------------------------------------------------------
Update Information:

Update to ClamAV 0.97.6

--------------------------------------------------------------------------------
ChangeLog:

* Sun Sep 23 2012 Dag Wieers <dag@wieers.com> - 0.97.6-1

- Updated to release 0.97.6.

--------------------------------------------------------------------------------
References:

 [ 1 ] Bug 7160 - SME7.6 Need to release clamav version: 0.97.6
       http://bugs.contribs.org/show_bug.cgi?id=7160

 [ 2 ] ClamAV 0.97.6 Release Announcement
       http://www.gossamer-threads.com/lists/clamav/announce/55863

 [ 3 ] ClamAV 0.97.6 Changelog
       http://github.com/vrtadmin/clamav-devel/blob/0.97/ChangeLog
--------------------------------------------------------------------------------
Updated packages:

clamav-0.97.6-1.el4.rf.i386.rpm
clamav-db-0.97.6-1.el4.rf.i386.rpm
clamd-0.97.6-1.el4.rf.i386.rpm
clamav-0.97.6-1.el4.rf.src.rpm 

This update can be installed with the Software Installer from the Server Manager.
http://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Chapter13#Software_Installer_Panel

MANAGING UPDATE AND RELEASE NOTES USING RNOTES.

Ian Wells has over the years developed a webpage intended to assist in the management of pending updates and the creation of release notes. It consists of a number of perl scripts that generate a site at http://wellsi.homeip.net/rnotes/. Whilst the information found there is not essential to any update, it is a valuable tool designed to streamline the overall process. It does an analysis of the packages in smeupdates-testing (both SME 7 & SME 8) and tries to work out what can be released, and if there are problems.

The site is subdivided into one html file per SME Server release, it updates every 8 hours.

SME 8: http://wellsi.homeip.net/rnotes/sme8/8bugreport.html

SME 7: http://wellsi.homeip.net/rnotes/bugreport.html

Each of the section above have a number of tabs, they are:

Summary

Summary of bugs for relevant version of SME on the day of query

Overview

Release Notes Overview - Work in progress - on the day of query

SRPMs

SRPMs content (note that the SRPMs list may be shorter than the RPMs list because some SRPMs generates multiple RPMs depending on the .spec file).

RPMs

RPMs content.

Bug Report

Report of packages associated with each bug. there are also links to relevant Bugs (click on the Bug number) and to an automated release notes (click on "notes"). One can also access ALL draft release notes for sme7 and sme8 by just looking at http://wellsi.homeip.net/rnotes/notes/

Status.

Status of each bug. The bugzilla product is highlighted if not matching the SME Version You may see entries like ‘7026 <No Product Found> Access Denied’ that means it is a security bug.

Simple.

A simple list of bugs

Missing Bugs Numbers.

Changes without bug numbers - should always be empty if our devs remember to include a bug number in the changelog.

Verified Package Versions

This gives some hints as to which packages can be released to smeupdates - if it’s all green then it should be good to go.. It does not yet check the depends/blocks from bugzilla. It also only goes green when a bug and all dependents are Verified. When it cannot retrieve the status (as is the case with security bugs) it marks them as NA and colours them black, manual checking is advised.

Smetest Files

This lists packages provided as part of a SME Server release which have a newer version in smetest. It is likely that these should be moved to smeupdates-testing.

Note 1: when compiling status of updates it is good to cross-reference the actual packages (RPMs) in the release queue (smetest/smeupdates-testing) with the bugzilla matrix and investigate where they don't match.

Note 2: final release notes consist of a script generated templates with some manual additions. Ideally the only changes needed to the automatically generated release notes would be the description of the update, in the part ‘<Insert Update Text Here>’ in the template. What was wrong, what was fixed, and any additional end-user information. This is the only challenging part. It is good to put links to additional information in the References section, as an example, check the release note for clamav 0.97.6-1 above.

Note 3: the template is only an aid, it may not be correct. You should check that:

- The version/release match the changelog

- The bug in references match the changelog - for security bugs, this needs to be added manually

- The RPMs & SRPMs listed match the changelog

UNDERSTANDING PACKAGES IN SMETEST AND SMEUPDATES-TESTING

To help people learn about how to release updates for SME Server, here are some comments based on the situation with SME 7 on the 21st November 2012 - note that the situation has changed significantly since this was written.

Starting with SME 7, look at the VERIFIED link in the bug matrix.

It is currently showing two:

7086 need to fix mirrorlist away from ibiblio

7160 SME7.6 Need to release clamav version: 0.97.6

Now look at smetest & smeupdates-testing and see that there are a lot more packages. They may not need to be released, but at least they need to be understood.

Packages found in smetest: /smeserver/releases/7/smetest/SRPMS (includes contribs & upstream)

clamav-0.97.6-1.rf.src.rpm

e-smith-base-5.0.0-17.el4.sme.src.rpm

fping-3.3-1.rf.src.rpm

fping-3.4-1.rf.src.rpm

gifsicle-1.67-1.rf.src.rpm

nagios-plugins-1.4.16-1.rf.src.rpm

perl-DBI-1.621-1.rfx.src.rpm

perl-NetAddr-IP-4.061-1.rf.src.rpm

pv-1.3.1-1.rf.src.rpm

qpsmtpd-0.83-0.9.el4.sme.src.rpm

rkhunter-1.3.8-2.el4.src.rpm

smeserver-durep-1.3.0-4.el4.sme.src.rpm

smeserver-durep-1.3.0-5.el4.sme.src.rpm

smeserver-durep-1.3.0-6.el4.sme.src.rpm

smeserver-htbwshaper-1.0-14.el4.sme.src.rpm

smeserver-mailstats-0.0.3-15.el4.sme.src.rpm

smeserver-qpsmtpd-2.0.0-8.el4.sme.src.rpm

smeserver-qpsmtpd-2.0.0-9.el4.sme.src.rpm

smeserver-sme7admin-1.1.1-23.el4.sme.src.rpm

smeserver-subversion-1.4-51.el4.sme.src.rpm

smeserver-webshare-1.0.0-10.el4.sme.src.rpm

smeserver-zabbix-agent-0.1-51.el4.sme.src.rpm

smeserver-zabbix-agent-0.1-52.el4.sme.src.rpm

unrar-4.2.3-1.rf.src.rpm

Packages found in smeupdates-testing: /smeserver/releases/7/smeupdates-testing/SRPMS/

clamav-0.97.5-2.rf.src.rpm

e-smith-apache-2.0.0-7.el4.sme.src.rpm

e-smith-backup-2.0.0-38.el4.sme.src.rpm

e-smith-base-5.0.0-16.el4.sme.src.rpm

e-smith-email-5.0.0-10.el4.sme.src.rpm

e-smith-pop3-2.0.0-2.el4.sme.src.rpm

qpsmtpd-0.83-0.8.el4.sme.src.rpm

All the non-contrib packages from smetest should be moved to smeupdates-testing for verification/testing. Essentially if you can find an older package in smeos then the package should be moved to smeupdates-testing.

Note that smetest has two versions of smeserver-qpsmtpd, only move the one that you want to smeupdates-testing Also note the (soft) dependencies, Bug 6141 involves e-smith-base & smeserver-qpsmtpd.

Packages to be moved from smetest into smeupdates-testing fall into two distinct categories:

a) “SME Server Core packages”

e-smith-base-5.0.0-17.el4.sme.src.rpm * Wed Jul 18 2012 Ian Wells <esmith@wellsi.com> 5.0.0-17.sme - Make CipherSuite secure by default [SME: 6141]

qpsmtpd-0.83-0.9.el4.sme.src.rpm * Wed Jul 18 2012 Ian Wells <esmith@wellsi.com> 0.83-0.9.sme - Fix fatal errors when mail has no headers [SME: 6386]

smeserver-qpsmtpd-2.0.0-9.el4.sme.src.rpm * Wed Jul 18 2012 Ian Wells <esmith@wellsi.com> 2.0.0-9.sme - Revert the 2.0.0-8 change and fix properly in e-smith-base [SME: 6141]

b) “upstream” packages

clamav-0.97.6-1.rf.src.rpm
perl-DBI-1.621-1.rfx.src.rpm
perl-NetAddr-IP-4.061-1.rf.src.rpm
pv-1.3.1-1.rf.src.rpm

Once all the relevant packages are in smeupdates-testing some sensible discussion can be had on what testing is outstanding, and what can be released.

PACKAGES UPDATE CYCLE

The life of packages under the responsibility of the updatesteam starts in smetest. Leaving aside contribs (they are the responsibility of individual maintainers), there are three distinct scenarios:

Scenario One: SME modified packages

Step one. Packages created in smetest should be summarely tested by the developer to ensure that it installs correctly. Particular attention should be given to accurate changelog including a reference to the bug report. The bug is then resolved FIXED, and a copy of the changelog including package name provided at time of resolution.

Step two. The package can then be moved by the developer to smeupdates-testing. In practice, members of the updatesteam should ensure that the move has been done, and move all relevant packages on a weekly basis.

Step three. Verification takes place, the bug is either REOPENED or resolved VERIFIED. Updatesteam to circulate request for comment about release after having ensured that all deps are satisfied. This could be scheduled in batch weekly unless urgent fix.

Step four. The package is then moved to smeupdates for release, release notes issued and possibly announce in the Forums if applicable. This could be scheduled in batch weekly unless urgent fix.

Scenario Two: clamav packages

Step one. Updatesteam raises a bug as soon as packages appear in smetest.
Step two. Moved to updates-testing.
Step three. Fast track verification and release + release notes.

Scenario Three: Upstream packages and kernel mods excluding clamav

Step one. Identify relevant packages by looking at all the RPMs, Changelogs, and Bugzilla. To find the upstream RPMs compare smetest to smeos. Rnotes simplify this process.

Step two. Relevant packages are moved to updates-testing.

Step three. Some testing may take place. To be clarified

Step four. If satisfied, packages are moved to updates.

Step five. No formal release notes, but Ian usually send an email and post to the forums a list of packages, e.g:

Subject: [updatesannounce] SME Server 7 Update: Upstream packages 01 December 2012
Date: 	Sat, 01 Dec 2012 18:28:21 -0800
From: 	Ian Wells <esmith@wellsi.com>
To: 	updatesannounce@contribs.org

SME Server 7 Update: Upstream packages 01 December 2012
Here is the list of upstream packages that were pushed as updates.
gifsicle-1.67-1.el4.rf.i386.rpm
perl-DBI-1.621-1.el4.rfx.i386.rpm
perl-NetAddr-IP-4.061-1.el4.rf.i386.rpm
pv-1.3.1-1.el4.rf.i386.rpm
___________________________________________
Announcement of maintenance updates for SME Server
To unsubscribe, e-mail updatesannounce-unsubscribe@lists.contribs.org
Searchable archive at http://lists.contribs.org/mailman/public/updatesannounce/

In some instances, centos upstream packages found in smetest and released by us do not show in yum updates notifications on servers in the field. This is because centos has released these packages before we do. We have centos repositories enabled as well as our repositories. We house all the packages necessary for the distro in our repositories. If we ever wanted to disable centos repostories we could do so and still continue to have people with functioning systems and receiving updates. It doesn't hurt (most of the time) to have the centos repositories enabled on servers in the field. It just makes systems get updates to upstream packages quicker. We really should be putting anything that people are able to pull from centos into smeupdates as soon as possible. (Shad)

ABOUT THE MIRRORS

Ibiblio appears to be unreliable, making it difficult to track changes. This is because Ibiblio is experiencing intermittent full hard drive issues. All downstream mirrors from them thus also have issues. Historically ibiblio was the place to see if packages had propagated out of the buildsys.

We've recently moved our primary mirror to the CA mirror (mirror.canada.pialasse.com). That is the one that you should check for what should actually be on the mirrors. You can always check to see what mirrors systems should be using for updates by looking at the mirrorlist files that are generated and housed on the CA master mirror.