Changes

9,861 bytes added , 07:22, 23 December 2018

Line 1: Line 1: +

'''This page is in a Draft stage and still requires additions and clarifications.'''

==OVERVIEW==

−

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

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

In order to help in the release cycle, mainly on pushing upstream packages at the right place, you can refer with some caution to this script : http://canada.pialasse.com/SMErepo/

===Repositories===

Line 15: Line 20:

===Package Categories===

====Sme modified packages.====

−

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

In the context of the updates cycles, these are packages found in smetest, smeupdates-testing or smeupdates for which an older package can be found in smeos (To be confirmed). Changelog generated in-house and includes a reference to a Bug in Bugzilla. Verification required before release.

====Upstream packages====

Line 22: Line 27:

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

This is a special case. Whilst initially 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.

====Initscript packages.====

This is a special case up to SME9 (including). Rebuild by SME every time upstream release a higher version to what we built. We import the new package in CVS and apply our patches.

so first import new srpm<syntaxhighlight lang="bash">

cd smeserver/rpms/initscripts/sme9

wget http://vault.centos.org/

../../common/cvs-import.sh -b sme9 -m "import initscript from centOS" initscripts-.....el6.centos.src.rpm

</syntaxhighlight>

second restore needed patches<syntaxhighlight lang="bash">

rm -f initscripts-9.03.31-runlevel7.patch initscripts-9.03.40-dmesg.patch initscripts-9.03.40-slapd_alias_ldap.patch initscripts-9.03.46-dont_run_plymouth_if_disabled.patch

cvs update -dPA

cvs update -p -r 1.2 initscripts-9.03.31-runlevel7.patch > initscripts-9.03.31-runlevel7.patch

cvs add initscripts-9.03.31-runlevel7.patch

cvs update -p -r 1.1 initscripts-9.03.40-dmesg.patch > initscripts-9.03.40-dmesg.patch

cvs add initscripts-9.03.40-dmesg.patch

cvs update -p -r 1.1 initscripts-9.03.40-slapd_alias_ldap.patch > initscripts-9.03.40-slapd_alias_ldap.patch

cvs add initscripts-9.03.40-slapd_alias_ldap.patch

cvs update -p -r 1.1 initscripts-9.03.46-dont_run_plymouth_if_disabled.patch > initscripts-9.03.46-dont_run_plymouth_if_disabled.patch

cvs add initscripts-9.03.46-dont_run_plymouth_if_disabled.patch

</syntaxhighlight>

For SME the patch to add in spec file:

Patch2000: initscripts-9.03.31-runlevel7.patch

Patch2001: initscripts-9.03.40-dmesg.patch

Patch2002: initscripts-9.03.40-slapd_alias_ldap.patch

Patch2003: initscripts-9.03.46-dont_run_plymouth_if_disabled.patch

in %setup we add :

%patch2000 -p1

%patch2001 -p1

%patch2002 -p1

%patch2003 -p1

then update the changelog, <syntaxhighlight>

%changelog

* date your name <email> - version release

- Rebase on upstream ...'''version'''... [SME '''...''']

- Don't try to run plymouth if disabled [SME: 8375]

Code from Charlie Brady

- Make slapd service an alias for ldap [SME: 8635]

- Add -n 1 to the dmesg line in rc.sysinit to prevent unwanted

messages appearing on the console [SME: 8277]

- Add hack for running rc7.d script during runlevel 4 [SME: 7217]

</syntaxhighlight>

the release version is the same as upstream and we add trailing release number :

Release: 1%{?dist}.1

If you are lucky the previous patches will still work, otherwise you will need to manually modify and create new patches.

==== Samba ====

As per SME 10 we build our own version of Samba from upstream in order to enable few functions to allow Samba AD usage. All modifications are done in the spec file.

the changes are the following :<syntaxhighlight lang="bash">

--- samba.spec.original 2016-10-02 16:23:04.356835288 -0700

+++ samba.spec 2016-10-02 16:31:38.311833030 -0700

@@ -38,1 +38,1 @@

-%global with_internal_ldb 0

+%global with_internal_ldb 1

@@ -59,8 +59,8 @@

%global libwbc_alternatives_suffix -64

%endif

-%global with_mitkrb5 1

-%global with_dc 0

+%global with_mitkrb5 0

+%global with_dc 1

%if %{with testsuite}

# The testsuite only works with a full build right now.

@@ -399,2 +399,3 @@

Summary: Samba libraries

Group: Applications/System

+Requires: libldb

@@ -463,7 +464,7 @@

Requires: %{name}-libs = %{samba_depver}

Requires: python-tevent

Requires: python-tdb

-Requires: pyldb

+#Requires: pyldb

Requires: pytalloc

Provides: samba4-python = %{samba_depver}

@@ -864,8 +865,8 @@

%endif

install -d -m 0755 %{buildroot}%{_unitdir}

-for i in nmb smb winbind ; do

- cat packaging/systemd/$i.service | sed -e 's@\[Service\]@[Service]\nEnvironment=KRB5CCNAME=FILE:/run/samba/krb5cc_samba@g' >tmp$i.service

+for i in nmb smb winbind samba; do

+ cat packaging/systemd/$i.service | sed -e 's@\[Service\]@[Service]\nEnvironment=KRB5CCNAME=/run/samba/krb5cc_samba@g' >tmp$i.service

install -m 0644 tmp$i.service %{buildroot}%{_unitdir}/$i.service

done

%if %with_clustering_support

@@ -1481,1 +1481,2 @@

%{_mandir}/man8/samba-tool.8*

+%{_unitdir}/samba.service

%else # with_dc

@@ -1738,6 +1743,7 @@

%{_libdir}/samba/libHDB-SAMBA4-samba4.so

%{_libdir}/samba/libasn1-samba4.so.8

%{_libdir}/samba/libasn1-samba4.so.8.0.0

+#%{_libdir}/samba/libdfs_server_ad.so

%{_libdir}/samba/libgssapi-samba4.so.2

%{_libdir}/samba/libgssapi-samba4.so.2.0.0

%{_libdir}/samba/libhcrypto-samba4.so.5

</syntaxhighlight>

here is how to upgrade the rpm from uptream.

cd /smeserver/rpms/samba/sme10/

make clean

make prep

cvs update -dPA

# here check the last revision of patch and reuse it

cvs status samba.spec.patch

# check the last version of samba and get its link in the following command

wget https://vault.centos.org/...../samba-4.6.2-12.el7_4.src.rpm

common/cvs-import.sh -b sme10 samba-4.6.2-12.el7_4.src.rpm -m "upgrade to samba-4.6.2-12"

cvs update -dPA

make clean

make prep

#update here the correct version of patch, ie 1.3 to something else

cvs update -p -r 1.3 samba.spec.patch > samba.spec.patch

cvs add samba.spec.patch

patch <samba.spec.patch

</syntaxhighlight>if patch fails, you need to update the patch, see bug https://bugs.contribs.org/show_bug.cgi?id=10429 as reference.

Then edit the spec file to add changelog lines and update release, commit and build. Ideally in the changelog paste the elements from previous spec files of SME related work, so we keep track

Also to note there are some upstream related package that should not be updated (ie, not pushed to smeupdates or smeos) without rebuilding samba locally first :

* libtevent

* python-tevent

also the following are exclude as they are build locally with samba srpm

* samba,samba-client,samba-client-libs,samba-common,samba-common-libs,samba-common-tools,samba-libs,samba*,libsmbclient,libwbclient

====Anaconda packages.====

This is a special case. We always rebuild our installed to include our special way. Here is the list of patch for SME9

Patch10001: 0001-anaconda.id.displayMode.patch

Patch10002: 0002-RemovePartitionTypeDialog.patch

Patch10003: 0003-SMEServerBranding.patch

Patch10004: 0004-UTC.patch

Patch10005: 0005-DegradedRAID1.patch

Patch10006: 0006-InstallerHDWarning.patch

Patch10007: 0007-VolGroup.patch

Patch10011: 0011-CheckArch.patch

Patch10012: 0012-CheckArch2.patch

Patch10013: 0013-Limit-languages.patch

Patch10014: 0014-Make-boot-loader-use-SME-labels.patch

Patch10015: 0015-Determine-upgradability-of-SME-server.patch

Patch10016: 0016-Automatically-upgrade-bootloader-if-necessary.patch

Patch10017: 0017-Headless-install.patch

Patch10018: 0018-RaidN.patch

Patch10019: 0019-UpgradeText-whitespace.patch

Patch10020: 0020-PreventTooOldUpgrades.patch

Patch10021: 0021-RaidN-v2.patch

Patch10022: 0022-InstallerLanguages.patch

Patch10023: 0023-remove_empty_line_in_lang_table.patch

then in %prep after %setup and centos patches add:

%patch10001 -p1

%patch10002 -p1

%patch10003 -p1

%patch10004 -p1

%patch10005 -p1

%patch10006 -p1

%patch10007 -p1

%patch10011 -p1

%patch10012 -p1

%patch10013 -p1

%patch10014 -p1

%patch10015 -p1

%patch10016 -p1

%patch10017 -p1

%patch10018 -p1

%patch10019 -p1

%patch10020 -p1

%patch10021 -p1

%patch10022 -p1

%patch10023 -p1

then update the changelog, the release version is the same as upstream and we add trailing release number :

Release: 1%{?dist}.1

If you are lucky the previous patches will still work, otherwise you will need to manually modify and create new patches.

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

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.

====Other packages to pay attention====

GeoIP on SME 8 and SME9: the package present in smetest should not be pushed (GeoIP-1.6.5-2), as it creates some conflicts. Hence, we keep GeoIP-1.4.8-1.

==BUILD SYSTEM==

Line 31: Line 231:

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:

Line 58: Line 257:

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

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.

Line 72: Line 271:

*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 multiple packages can be built from one rpm spec file/tarball/src.rpm).

Packages can be moved (mv) or copied (cp). However in Build, the deletion of files from folders is prohibited, thus (mv) will lead to a (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.

Line 131: Line 330:

==VERIFICATION==

−

~~Package~~ should be verified using the standard verification template on a clean system, check ~~http://wiki.contribs.org/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.

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 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 ~~dependancies involving other bugs To be clarified~~.

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.

Line 180: Line 379:

−

~~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 used~~ to ~~do normally and try to build~~ a ~~bug and package dependency graph To be confirmed.~~

There are two types of package dependencies to check before a release can take place:

−

~~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 when it is necessary to enforce dependencies between packages.~~

−

:b) ~~Soft~~ dependencies ~~relates~~ to .... ~~need definition~~

:a) Hard dependencies. These dependencies are specified in 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. The verification phase taking place before release should pick up hard dependencies which could break an update - the installation and testing of a new rpm will show whether things break or not. To the best of my understanding, the 'Verified Package Versions' tab in Rnotes does not track hard dependencies. To be confirmed.

:b) Soft dependencies. These dependencies occur when a package fixes three bugs and one of them has not been verified. As a result, and until all bugs associated with a particular package are verified, only an older version of that package can be safely released. Also note that unresolved soft dependencies may affect other packages if one of the fixes involves multiple packages. Luckily the 'Verified Package Versions' tab in Rnotes will track this - Rnote script do what Ian Wells used to do manually and try to build a bug and package dependency graph.

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

Line 217: Line 410:

*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

*It may 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.

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.

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. Accordingly, the script does not prevent the release of packages for which package dependencies have not been resolved.

{| style="color:red;background-color:#ffffcc;"

−

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

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

Line 233: Line 426:

==ISSUE RELEASE NOTES==

−

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

Wait for the mirrors to sync, and then email manually the release notes. Release notes can be prepared manually, or one can access ALL draft release notes for sme7 and sme8 by just looking at http://wellsi.homeip.net/rnotes/notes/ . Check the "Bug Report" in the section about RNOTES below for details.

Example of release notes:

Line 298: Line 491:

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

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.

Line 324: Line 517:

===Status.===

−

Status of each bug. The bugzilla product is highlighted if not matching the SME Version

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.

[You may see entries like ‘5908 NA <No Product Found> Access Denied’ that means it is a security bug.]

===Simple.===

Line 334: Line 527:

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

This gives some hints to which packages can be released to smeupdates.

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 it 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~~.

This tab lists packages provided as part of SME Server release which have a newer version. Only files that were on the ISO are checked and displayed - it is likely that these should be moved to smeupdates-testing. Note that Smetest may also contain other updated files related to contribs - and potentially other files. These are not displayed in RNotes and need to be sorted manually.

−

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.

Line 403: Line 598:

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 ~~What is the mechanism to track this soft dependency?~~

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:

Line 426: Line 621:

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

===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 two. The package can then be moved by the developer to smeupdates-testing. Essentially if you can find an older package in smeos then the package should be moved 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.

Line 436: Line 631:

:*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===

===Scenario Two: clamav packages===

:*Step one. Updatesteam raises a bug as soon as packages appear in smetest.

Line 442: Line 637:

:*Step three. Fast track verification and release + release notes.

−

===~~Third scenario~~: Upstream packages and kernel mods excluding clamav===

===Scenario Three: Upstream packages and kernel mods excluding clamav===

{| style="color:red;background-color:#ffffcc;"

This topic is incomplete and requires additional information

:*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.

Line 470: Line 670:

Searchable archive at http://lists.contribs.org/mailman/public/updatesannounce/

−

~~{| style="color~~:~~red;background-color~~:~~#ffffcc;"~~

'''Note 1:''': 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)

−

~~|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):~~

'''Note 2:''' Some packages found in smetest belong to smeaddons. If it isn't part of the distro then it doesn't go in smeupdates-testing. smeaddons is just like smecontribs but contains package that were necessary to aid upgrading from 7 to 8. They should be on a similar release schedule to what smecontribs would be. To be confirmed: where to move new packages associated with smeaddons? AND who is responsible for the release of smecontribs related packages (eg unrar)?

−

~~/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:~~

==ABOUT THE MIRRORS==

−

~~/home/chris/smereleases/releases/7~~.~~6/smeaddons/SRPMS/unrar-4~~.1.~~4- 1~~.~~rf.src.rpm~~

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.

−

~~How do you deal with this class~~ of ~~packages?~~

We've recently moved our primary mirror to a new set of mirrors:

*mirror.canada.pialasse.com : Canada, Montréal (known as the CA Mirror)

*mirror.pialasse.com : in France, Roubaix near Lille.

−

~~How do~~ you ~~generally deal with upstream packages not found in smeos?~~

The CA Mirror 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.

−

As an example:

http://mirror.canada.pialasse.com/mirrorlist/smeupdates-8

−

~~{| style="color:red;background-color:#ffffcc;"~~

Both mirrors can be used for rsync subject to being added to the list of allowed client (canadian server or french ones). Alternatively, mirrorservice.org has reopened their mirror with a 4 hour sync and a public rsync service ( they are based in UK and sync on the canadian mirror)

−

~~Issues~~ to ~~clarify for upstream packages listed~~ in ~~smetest~~ and ~~found in smeos:~~

−

~~In Rnotes for version 8, in test tab, we currently have two new packages likely to be moved to smeupdates-testing~~:

=== Current SME Server contribs.org Mirror Tree ===

[[Image:Smeserver_mirrors.png|600px| ]]

−

~~libxml2-2.6.26-2.1.15.el5_8.6.i386.rpm~~

this is the current tree of Mirror for SME Server, so we can see what mirrors are affected by issues or outages.

−

For a full list of our download mirrors see our [http://mirror.contribs.org/mirrors/ '''download locations''']

−

~~tzdata-2012i-2.el5.i386.rpm~~

[[Category:Howto]]

−

[[Category: Development Tools]]

−

~~This packages have already been release by Centos at time of writing.~~

−

~~==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~~.

−

~~As an example:~~

−

http://mirror.~~canada.pialasse~~.~~com~~/~~mirrorlist~~/~~smeupdates-8~~

−

~~{| style="color~~:~~red;background-color~~:~~#ffffcc;"~~

−

~~We will need to come up with a tree of which mirrors sync from where so we can see what mirrors are affected by issues or outages.~~

−

Unnilennium

Super Admin, Wiki & Docs Team, Bureaucrats, Interface administrators, Administrators

3,250

edits

Retrieved from "https://wiki.koozali.org/Special:MobileDiff/16832...37770"

Changes

Updates cycles (view source)

Revision as of 07:22, 23 December 2018

Navigation menu

Search