Archive for the ‘News’ category

Unbound 1.15.0 32/64-bit available

February 15th, 2022

Unbound version 1.15.0 has been pushed to unstable. This is the first package that contains 64-bit binaries, which allows Unbound to run a larger cache.

PHP 5.6.15 released

December 1st, 2015

We are glad to announce the release of PHP 5.6 to unstable. This replaces the PHP 5.3 packages. It contains also php5_module for Apache2.4 (ap24_modphp5).

Primary mirror will be down for the day

August 31st, 2015

Dear users, our primary mirror will be down for today due to hardware migration of our provider. In the meantime you can use the direct catalog from the buildfarm, although it has a slower internet connection as the primary mirror.

Sorry for the inconvenience — Dago

Apache 2.4.12 32/64bit available

June 24th, 2015

Apache 2.4.12 is pushed to unstable. This is the first apache package which contains also 64bit binaries. To activate the 64bit version run:

# svccfg -s cswapache24 'setprop general/enable_64bit = true'

wget 1.16.2

March 1st, 2015

Finally wget 1.16.2 has been released yesterday and I just pushed 1.16.2,REV=2015.03.01 to unstable/. This fixes CVE-2014-4877 (Absolute path traversal vulnerability).

GCC 4.9.2 released

November 25th, 2014

We are glad to announce the release of GCC 4.9.2 to unstable. Happy compiling!

Fix for OpenSSL vulnerability (Heartbleed bug)

April 9th, 2014

Our OpenSSL package was vulnerable to the recently discovered Heartbleed bug as described in CVE-2014-0160.
An updated package 1.0.1g,REV=2014.04.08 for OpenSSL 1.0.1g has been pushed to unstable, bratislava and kiel.

Roadmap for 2013

November 24th, 2012

Most of the year 2012 at OpenCSW was spent trying to keep up to date with core packages, and testing the new package flow. The unstable catalog was getting very frequent updates directly from package maintainers. The dublin catalog was periodically synchronized from the unstable catalog, until the OpenSSL update came along. The library update turned out to be non-trivial, and resulted in the dublin catalog freeze. We have the capacity to rebuilt packages for the dublin catalog, but most of the new work goes towards new packages.

We’ve created a new catalog called ‘kiel’. It is a snapshot of the unstable catalog, featuring OpenSSL 1.0.0 and other updates. If you want OpenSSL 1.0.0, this is the catalog you should use. It will kept getting periodic updates from unstable, the way the dublin catalog used to. You need to configure pkgutil to point to the release name.

We’ve also created the next catalog, called ‘bratislava’, which is currently only a placeholder for some experiments we’re about to make. We’re still collecting ideas, but the main one is that we’ll build it from scratch, with some fundamental changes: there will be no CSWcommon, and everything will be built with GCC by default. We also want to make it possible to bootstrap OpenCSW at a different prefix than /opt/csw, allowing others to build their own software stacks based on our code base.

The progress on the IPS catalog is slow, but the effort is ongoing.

The short outline of our 2013 plans is:

  • Keep the ‘stable‘ URL empty for until mid-2013 to make sure that people notice that they shouldn’t be using it.
  • When mid-2013 arrives, promote dublin to stable and promote kiel to testing.
  • Build bratislava.
  • Build an IPS catalog.

We hope our packages make your life easier. If you feel like talking to us, hop on the IRC channel.

Spring cleaning

April 16th, 2012

During the Wintercamp in Bratislava this weekend, we have dropped from the catalog a number of packages which we considered not useful. Some packages were just too old, or newer versions were available elsewhere. Others were discontinued projects, or packages that simply don’t work any more. The full list of dropped packages (with comments) is available in the Wintercamp 2011 minutes document.

If we happened to drop something that you care about, give us a shout! You can request the package through the request form, or talk to us on IRC at #opencsw on Freenode.

Which catalog should I use?

January 15th, 2012

In November 2011, we’ve announced a new catalog layout. For some users, the choice of the catalog might be unclear; “should I use the testing, or the unstable catalog?” (The stable catalog is dead.)

The short answer is: it’s best if you use both testing and unstable.

Let’s consider the alternative: using only one catalog on all machines. If you use unstable (also in production), you’ll keep getting a lot of updates, and chances are that some of them will be broken. On the other hand, if you use only the testing catalog, there will be less churn, but you won’t spot problems in packages while they’re in unstable and you will increase chances of a bad package push to testing.

If you run a site where you have production and development / testing machines, you can use the unstable catalog for the ones that have higher instability tolerance. If anything breaks in unstable, you’ll notice the problem but it won’t be an operational issue for you. If you get back to us with a report, we’ll fix the it, and the bug won’t make it into the testing catalog.