I'm building Audacious 2.4.2 in Rawhide, and once available in the koji build
root, this will require rebuilds of the separate _plugin_ packages.
The tools/apps linked with Audacious' core libraries are not affected:
2.4.2 is the first maintenance release in the [supposed to be stable] 2.4
branch, but bumped the generic plugin API to version 17 nevertheless.
Quite early in 2.4.x development actually. Plugins, if not rebuilt, would
refuse to load.
The rebuilds should be possible without problems. If run you into
anything unexpected, feel free to contact me.
I'm currently in process of automatic enlisting of all ~10K Fedora Git
repos at Ohloh. Right now roughly 7% of repositories were added and
overall process will be finished in a 20-30 hours (it takes me about
5-10 seconds to properly add repository, and I don't want to speedup
this process - to prevent Ohloh from accidental DoS).
With best regards, Peter Lemenkov.
Since MySQL AB^W^WSun^WOracle has now declared the mysql 5.5.x release
series to be GA status, I'm planning to push it into rawhide shortly to
replace the 5.1.x series. Theoretically, this will go pretty smoothly.
I'm aware of a couple of ABI-level issues:
1. libmysqlclient.so, which is linked into all manner of stuff, is
supposed to be ABI-compatible with the previous releases. However,
I got tired of the amount of visible churn in exported-symbols-you're-
not-supposed-to-use. The new release will use a linker --version-script
to hide everything except the documented API functions. This might
break any apps that are relying on non-API functions. If so, I'm
willing to consider on a case-by-case basis whether to add those symbols
back to the ABI or fix the callers.
2. libmysqlclient_r.so is gone altogether; there's no need for it since
the regular libmysqlclient.so library is supposed to be thread safe.
AFAIK this will require rebuilding only the following packages:
For now I'll include a symlink libmysqlclient_r.so -> libmysqlclient.so,
so that a simple rebuild with no source-code changes should be
sufficient. Eventually we'll probably want to fix the source code to
not refer to libmysqlclient_r, but that might take awhile if upstreams
are worried about portability.
There are also some SQL-level incompatibilities called out here:
I'm not sure to what extent these may affect Fedora applications,
but it seems like the easiest way to find out is to try them.
Any objections? Anything people think should be tested before pushing?
regards, tom lane
W dniu 3 grudnia 2010 09:14 użytkownik Michał Piotrowski
> What services are installed by default when installong form Live
> GNOME/KDE/etc and DVD?
Ok, let's ask the question differently - what services should be run
by default to provide working system for desktop user?
IMO ssh can be off by default and should be started only if user tries
to connect over port 22.
Do we really need to install iptables/ip6tables by default (it's in core group)?
Sent from my iToaster
as discussed some time ago, I worked on the proof of concept
implementation of firewalld. FirewallD is a service daemon with a D-BUS
interface that provides a dynamic managed firewall.
For more information on firewalld, please have a look at:
About this version:
This is mostly the proof of concept implementation with some changes and
is feature complete for F-15 as a firewalld preview version. It will not
be enabled per default and will also not get installed per default. The
system-config-firewall with static firewall model will still be the
default firewall solution for Fedora 15.
What this firewalld version can do:
- It supports most of the firewall features system-config-firewall had,
but there are three limitations:
1) custom firewall rule files (iptables save format) are not
supported and most likely will never be, but there is support for
custom rules (limited functionality).
2) sysctl changes for ip_forward are not done, yet.
3) There are no permanent firewall settings, this means that all
settings are lost after a service restart or reboot. Permanent
firewall settings will be added later on.
- The firewall daemon manages the firewall dynamically. This means that
changes are done without recreating the whole firewall. Also there is
no need to reload all firewall modules anymore. Firewall helpers are
loaded and unloaded if needed.
- A simple tray applet (firewall-applet) shows the status of the public
firewall and is makes it simple to enable and disable firewall
services. The applet does not show firewall configuration settings
done with the libvirt interface.
- firewall-cmd is the command line client that makes it possible to
enable, disable, query and list firewall features. firewall-cmd is
also not able to show firewall settings of the libvirt interface.
- There is an rule and chain interface for libvirt, but the PolicyKit
policy is not in place, yet.
What this version can not do (future features):
- firewall-config, the firewall configuration utility, is not functional
- System vs. User/Session configuration
- Zone support
- NetworkManager firewall rule support
firewalld made it into a fedorahosted repo at:
The fedoraproject wiki page at
exists and will get more updates soon. The feature request page for
Fedora 15 is also up to date:
For test packages, please have a look at
firewalld has a requirement for system-config-firewall-1.2.28. This
version has checks for an active firewalld in the tools.
Please have a look at
for the Fedora 15 packages of this version. It is usable on fedora
versions < 15.
How To Test
- Install firewalld and firewall-applet
- Start the firewalld service
- Start the tray applet firewall-applet
- Use firewall-cmd to enable for example ssh:
firewall-cmd --enable --service=ssh
- Enable samba for 10 seconds:
firewall-cmd --enable --service=samba --timeout=10
- Enable ipp-client:
firewall-cmd --enable --service=ipp-client
- Disable ipp-client:
firewall-cmd --disable --service=ipp-client
- To restore your static firewall with lokkit again simply use:
You can also use the D-BUS interface directly. This is required for
libvirt (and later on also NetworkManager). The D-BUS interface
documentation is work in progress and will be added later on.
Comments and additional information is highly welcome.
Thanks in advance,
Software Engineer Phone: +49-711-96437-310
Red Hat GmbH Fax : +49-711-96437-111
Hauptstaetterstr. 58 Email: Thomas Woerner <twoerner(a)redhat.com>
D-70178 Stuttgart Web : http://www.redhat.de/
Hi, everyone. So, in the recent debate about the update process it again
became clear that we were lacking a good process for providing
package-specific test instructions, and particularly specific
instructions for testing critical path functions.
I've been working on a process for this, and now have two draft Wiki
pages up for review which together describe it:
the first isn't particularly specific to this, but it was a prerequisite
that I discovered was missing: it's a guide to test case creation in
general, explaining the actual practical process of how you create a
test case, and the best principles to consider in doing it.
The second is what's really specific to this subject. It describes how
to create a set of test cases for a particular package, and a proposed
standardized categorization scheme which will allow us to denote test
cases as being associated with specific packages, and also denote them
as concerning critical path functionality.
Given that mediawiki has a handy API which also allows you to deal with
categories, this should make it easy to both manually and
programmatically derive a list of test cases for a given package, and a
list of *critical path* test cases for a given package. You can do this
manually, but I also envision Bodhi and fedora-easy-karma utilizing the
API so that when an update is pushed for a package for which test cases
have been created under this system, they will link to those test cases;
and when an update is pushed for a critical path package, they will be
able to display separately (and more prominently, perhaps) the list of
test cases relevant to the critical path functionality of the package.
Comments, suggestions and rotten fruit welcome :) I'm particularly
interested in feedback from package maintainers and QA contributors in
whether you feel, just after reading these pages, that you'd be
confident in going ahead and creating some test cases, or if there's
stuff that's scary or badly explained or that you feel like something is
missing and you wouldn't know where to start, etc.
The trac ticket on this is probably valuable for background, explaining
why some things in the proposal are the way they are:
it also mentions one big current omission: dependencies. For instance,
it would be very useful to be able to express 'when yum is updated, we
should also run the PackageKit test plan' (because it's possible that a
change in yum could be fine 'within itself', and all the yum test cases
pass, but could break PackageKit). That's rather complex, though,
especially with a Wiki-based system. If anyone has any bright ideas on
how to achieve this, do chip in! Thanks.
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
I'm not sure if there's a better list for this to go to, but there seems
to be a problem generating deltarpms for F14 OOo (and a few other
packages) on releng2. Specifically, the updates->updates deltarpms
aren't being generated, while the GA->updates deltarpms are.
When I checked the mash.out log for the 101202.1757 push, there are
loads of error messages following the form of:
Error genDeltaRPM for openoffice.org-langpack-pt_PT: exitcode was 256 -
Reported Error: bad cpio archive
The problem is that this error normally comes up when one of the rpms is
corrupt, but manually running deltarpm between an rpm from the
101201.1909 push and the update from the 101202.1757 push results in a
proper drpm and no errors.
As far as I can see, this only affected the openoffice.org* and
autocorr* packages in the 101202 push, and the rest of the packages in
the push had all the proper deltarpms generated.
I'm not sure where to go from here. Any ideas on how to track this
Some time ago, the Fedora default target for 32 bit Intel system moved
from i386 (F10) via i586 (F11) to i686 (F12). Nevertheless, even the
current development repo contains recent builds ending with
*.fc15.i386.rpm. Is there a particular reason for these exceptions or
has the build target been chosen incorrectly? ~CF