Updates cycles
1.- OVERVIEW The SME Server update and maintenance cycle consists in 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 including 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.
2.- 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).
Smetest can have multiple versions of a package, maybe the three newest. I am not aware whether they are archived. As they are built from CVS it should be possible to recreate one if really needed.
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.
3.- 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 scripts. 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 one SRPM will generate one or more RPMs depending on the .spec file).
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.
Let move them to smeupdates-testing for verification and future release: a) SSH into contribs.org b) 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
4.- VERIFICATION Package should be verified using the standard verification template on a clean system. The verification phase should pickup hard dependencies which could break an update, and check for correct changelogs, including a reference to a bug number in bugzilla.
5.- 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 dependancies involving other bugs.
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: a) SSH into contribs.org b) 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) Isssuing 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.
6.- DEALING WITH PACKAGE DEPENDENCIES. The verification phase taking place before release should pick up hard dependencies which could break an update. What needs to be checked is where a package fixes three bugs and one was not verified. That 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. Note that the 'Verified Package Versions' tab in Rnotes will track this - it does what Ian used to do normally and try to build a bug and package dependency graph.
We can distinghish between "hard" and "soft" dependencies referred to in this document as follows:
a) Hard dependencies are those from the spec file, eg: requires: e-smith-lib >= 2.0.0-2 Developers put these when it is necessary to enforce dependencies between packages.
b) Soft dependencies relates to package dependencies setup in Bugzilla. As an illustration, 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 & e-smith-apache in the example above, but safest not to.
To be clarified: - If deps are not resolved, will Shad's script block cp for unresolved packages dependencies? [Answer from Ian: not sure for updates. But normally it is not hard dependencies being an issue. ]
7.- 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
8.- 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 design 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
9.- 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.
10.- 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:
First scenario: 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.
Second scenario: 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.
Third scenario: 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/
Issues to clarify for upstream packages NOT found in smeos:
For version 7.6, in test, we find a package not listed in Rnotes dated June 2012 (test tab):
/home/chris/smereleases/releases/7.6/smetest/SRPMS/unrar-4.2.3- 1.rf.src.rpm
An older package can be found in smeaddons dated Jan 2012: /home/chris/smereleases/releases/7.6/smeaddons/SRPMS/unrar-4.1.4- 1.rf.src.rpm
how do you deal with this class of packages? How do you generally deal with upstream packages not found in smeos?
10.- 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.
Observation: I just refreshed (rsync) my tree against distro.ibiblio.org::smeserver 1354247245 - www.smeserver.org - Fri, 30 Nov 2012 03:47:25 +0000
Traces are: Fri Nov 30 03:48:16 UTC 2012 Used ftpsync version: 80387 Running on host: canada.canada.pialasse.com
Fri Nov 30 03:48:27 UTC 2012 Used ftpsync version: 80387 Running on host: login1.ibiblio.org
Question: When doing rsync from Ibilbio, are we pulling packages from the new primary mirrors at pialasse.com only, or a mix of Ibiblio and CA?