I send this email to inform you that we have
released under GPL-3.0 two
- SaltOS: is an ERP / CRM / Management Suite,
ideal for freelancers and SMEs.
- RhinOS: is a solution to have a professional
website, ideal for any web
You can find more information at http://www.ws3.es
I would like to suggest these programs (especially
SaltOS) as tools to be
included in the Fedora distribution. What do we
do? Where do we contact?
We remain at your disposal for any clarification
Josep Sanz (josep.sanz(a)ws3.es)
I hereby want to let everybody know that in the next days I will turn on
/var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance
with the following accepted F15 feature:
My current tests indicate that we will not run into too much trouble
with this and most things should continue to work just fine. However, of
course I run only a small subset of packages of the fedora archive on my
machine. So here's what might happen and which might need fixing over
the next weeks in various packages:
- Not all packages might be able to create their directory in /var/run
on start-up. Since SUSE and Ubuntu have already been shipping systems
with tmpfs on /var/run and /var/lock for quite a while I expect the
number of packages that are incapable of doing this to be very
small. If your software nonetheless fails witht this issue, then
there are two options to fix this: a) patch the program in
question, so that it is able to recreate the directories in
/var/run, or b) ship a simple drop-in file for /etc/tmpfiles.d/ which
recreates these directories on boot. (see below)
- There might be permission problems, since the rpms might have set
different perms on the subdirs of /var/run than the software itself
might apply when starting up. In this case, a drop-in file in
/etc/tmpfiles.d/ might help. (see below)
- The SELinux policy might trigger AVCs and disallow creation of the
dirs in question. In this case Dan will be of help of course, so make
sure to file a bug. And I guess I don't need to mention this but
temporarily falling back to permissive mode is a short-term workaround
- In some cases daemons might want to create more than one file/dir
below /var/run which are supposed to be labelled differently. In this
case the daemon can either be modified to fix its labels up itself, or
a drop-in file in /etc/tmpfiles.d/ might help (see below).
- Many .spec files currently own subdirs of /var/run. These need to be
updated to %ghost those dirs only, so that the automatic removal of
these files/dirs on boot doesnt cause rpm to complain. The list of packages
which own such files/subdir you find on the aforementioned feature
page. I will mass-file bugs against these packages later tonight,
requesting the %ghosting of these entries. For more information on the
%ghost directive in .spec files see this page:
a) Lennart will mass-file bugs regarding %ghost usage tonight
b) Lennart will switch on /var/run and /var/lock on tmpfs either
tomorrow or the day after tomorrow
c) YOU need to edit your .spec file and place a %ghost where
c) YOU need to test if you package still works, and if necessary file
AVC bugs, add an /etc/tmpfiles.d drop-in file to your program, or patch
it so that it is able to recreate these directories beneath /var/run on
This is a new feature of systemd, but which is apparently very much
liked by people outside of systemd, so this might actually find adoption
even on systems which will not adopt systemd any time soon, since it
actually is not specific at all to systemd. By dropping a simple
configuration file in /etc/tmpfiles.d you can ensure that volatile files
and directories are: a) created, deleted or emptied at boot b) their
permissions/ownership fixed c) its directory contents cleaned up in
regular intervals (a la tmpwatch) and d) it is properly relabeled at
As an example, here's how such a file might look like for the screen package
(name it /etc/tmpfiles.d/screen.conf):
d /var/run/screens 1777 root root 10d
d /var/run/uscreens 0755 root root 10d12h
This encodes that two directories are created under the listed names, with
automatic clean up after 10 days resp. 10 days and 12h.
For more details consult the man page:
Thank you for your attention!
Lennart Poettering - Red Hat, Inc.
devel-announce mailing list
This patch (with .rpms for x86_64 and i686) enables glibc optionally
to detect, diagnose, and work around overlap in memcpy/mempcpy:
The option to check is controlled by an environment variable
MEMCPY_CHECK_ which influences choices made by __init_cpu_features
and the STT_GNU_IFUNC mechanism for choosing alternate implementations
at runtime. The patch extends the IFUNC mechanism by passing
&getenv as an actual argument. If MEMCPY_CHECK_ is unset or 0, then
there is no runtime overhead at all when calling memcpy. Setting
MEMCPY_CHECK_ nonzero enables detection, diagnosis, and work-around
using memmove. The runtime cost of detecting no overlap is about
4 or 5 cycles per call to memcpy or mempcpy.
A previous thread "Fixing the glibc adobe flash incompatibility"
The patch demonstrates what is possible. It is one example
of a selective diagnostic tool that may be useful in some cases.
Other tools such as valgrind(memcheck) may be preferable for
Looking at the new architecture-dependent implementations of memcpy
for i686 and x86_64, it seems that overlap makes no difference
for lengths of 40 bytes or less (i686) or 80 bytes or less (x86_64).
The new code copies short source regions entirely into registers
before storing any bytes at the destination. Thus the implementation
might move the check for overlap into the branch for long regions only.
The 4 or 5 cycles would be an almost insignificant overhead, particularly
in relation to the claimed savings of hundreds of cycles for the
This is a report of the weekly KDE-SIG-Meeting with a summary of the
topics that were discussed. If you want to add a comment please reply
to this email or add it to the related meeting page.
= Weekly KDE Summary =
Time: 2010-11-30 14:00 UTC
Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-11-30
Meeting minutes: http://meetbot.fedoraproject.org/fedora-meeting/2010-11-30/kde-
Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2010-11-30/kde-
= Participants =
= Agenda =
topics to discuss:
* kde 4.5.4 status
* knetworkmanager: vpnc, pptp, opnvpn on live images? 
= Summary =
kde 4.5.4 status
* than is reuploading kde 4.5.4 tarballs as upstream accidentally tarred the
* rdieter to set up f13/14 kde 4.5.4 buildtarget
knetworkmanager: vpnc, pptp, opnvpn on live images?
* all dependencies are just 1 mb
* AGREED: make the kde-plasma-networkmanagement-* subpackages default
instead of optional in comps
* Kevin_Kofler to update comps according accepted proposal (done )
* Kevin_Kofler fixed xsettings-kde to support GTK+ app menu icons properly
= Next Meeting =
= Links =
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc. http://cz.redhat.com/
I've stopped using aumix a while ago -- it needs snd-mixer-oss.ko to
work, which no longer gets loaded by default. I loved the layout (much
cooler than alsamixer), and while I would prefer something with a
similar look and feel to do what pavucontrol does right now, I don't
have the spare cycles to hack it up myself. So, I guess it's time to
say goodbye to an old friend, and put it up for adoption/retirement.
----- "Toshio Kuratomi" <a.badger(a)gmail.com> wrote:
| corner cases:
| * After installation but before reboot, the application is able to
| and write to a directory in /var/run and/or /var/lock
This is the case what I want to know a solution. though no one is giving me an answer for my question yet.
| 2) The act of installing the rpm should create the necessary
| Alternately, the program (or as you say, the init script) can create
| necessary directories. Note that I don't believe that systemd gives
| you the
| flexibility to do that sort of thing (there's no "script" in its init
| so you'd need a wrapper script for the program itself or write a patch
| the program itself to achieve this where the program doesn't create
| directory already and if we don't do this from within the rpm
To get this working on SELinux, are we presuming that restorecond is running on the system or does the package maintainer need to take care of running restorecon manually in the script or the program?
Just a quick heads up - I'm currently building Clutter 1.5.8 into
Supposedly this is 100% compatible with Clutter 1.4, but there are a lot
of internal changes in the backend parts so there's a possibility of
(I was waiting to upgrade in Rawhide until we got the necessary bugs
fixed to make it work well with GNOME Shell; 1.5.8 achieves that.)
If you run into anything, just file it in bugzilla and I'll take care of
investigating and upstreaming as necessary.
I have just moved ghc-7.0.1 and a large set
of Haskell ghc package rebuilds into dist-f15
The main stacks have been rebuilt: darcs,
haskell-platform, xmonad, and gtk2hs.
Rebuilds still pending include xmobar, hlint,
and various libraries (currently with one or less dependents).
Any rawhide package that depends on a Haskell library
and hasn't already been rebuilt, must be rebuilt with ghc-7.0.1.
You can read more about ghc-7.0.1's new features in the release-notes:
This work is part of https://fedoraproject.org/wiki/Features/GHC70
If you need help with rebuilding a package with ghc-7.0.1
please contact me, #fedora-haskell or haskell-devel list.
Testing and feedback of the new packages in rawhide is most welcome
in bugzilla or mailing-list.