Hello,
I'm trying to package syslog-ng 3.2-git, and ran into some troubles.
V3.2 has an interesting new feature, called SCL (system configuration
library), which tries to ease syslog-ng configuration. This works nicely
when apparmor is disabled.
SCL uses a script to generate part of the configuration. So, when
system(); is used in syslog-ng.conf, it actually calls a script, which
generates the missing parts based on the OS. In case of Linux, it's:
linux-6y8u:~ #
/usr/share/syslog-ng/include/scl/system/generate-system-source.sh
unix-dgram("/dev/log");
file("/proc/kmsg" program-override("kernel") flags(kernel));
When apparmor is enabled, this script is not run, instead I see
"permission denied" in the strace output.
Question: how should I modify /etc/apparmor.d/sbin.syslog-ng to be able
to run external scripts and/or applications. This is not only a problem
for SCL, but syslog-ng can use these both as log source and destination.
Once a solution is know, I'd put some comments in sbin.syslog-ng, so
users could extend the AppArmor ruleset easily instead of disabling it...
Bye,
--
Peter Czanik (CzP) <czanik(a)balabit.hu>
BalaBit IT Security / syslog-ng upstream
http://czanik.blogs.balabit.com/
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Forward this from the linux-xfs list, in hoping that decision-makers will
consider XFS as the default suse OS install choice.
It continually bests other file systems in optimized configuration performance tests
and these new improvements sound like they only add more speed to the equation.
For nearly all systems, disk speed is the bottle neck, so using the best solution
possible should be strongly considered the default choice for all users -- regardless
of 'political' concerns (which seem to often over-rule practicality, unfortunately).
Linda
p.s. I am not part of the xfs project. I've just used it with open suse (or previously,
Suse) since ~ 2002 and have never regretted it.
Current filesystem read rates using XFS are about 1GB/second on sustained multi-gigabyte
reads.
Using 1Gbit ethernet, Samba gets 97MB/s read from disk to 115 MB/s read from memory
and 125MB/s writes to memory or disk.
-------- Original Message --------
Subject: observed significant performance improvement using "delaylog" in a real-world application
Date: Tue, 10 Aug 2010 18:01:33 +0200
From: Peter Niemayer <niemayer(a)isg.de>
To: linux-xfs(a)oss.sgi.com
Hi all,
we use XFS for a very I/O-intensive, in-house developed real-time
database application, and whenever we see new or significantly changed
file-systems becoming available, we run a benchmark using this
application on a conserved, fixed real-world data set.
I'm pleased to state that using the experimental "delaylog" mount option
(in vanilla linux-2.6.35) we measured a 17% performance increase
for our benchmark scenario. (Other mount-options in use both before
and after the "delaylog" option: noatime,nodiratime,nobarrier)
That's a lot given that XFS was the fastest performing file-system
for this application already.
It's also a promising result regarding stability, as several other
tests (using e.g. reiser4 or ceph) in the past led to crashes in the
same benchmark scenario.
So thanks to all contributing developers for this significant optimization!
Regards,
Peter Niemayer
_______________________________________________
xfs mailing list
xfs(a)oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi!
My original plan has been to have glibc-2.13 in 11.4, however it is
still completely unclear when will it be actually released. In case it
is not soon enough, I would prefer to stay with glibc-2.11 in 11.4
instead of upgrading to glibc-2.12.
Downsides are not terribly huge:
- Missing these:
* New interfaces: pthread_getname_np, pthread_setname_np
* New Linux interface: recvmmsg
* STT_GNU_IFUNC implemented for Sparc by David Miller.
* The dynamic linker now recognizes supported ABI versions from
the EI_ABIVERSION field in the ELF header.
* New locales: kok_IN, sq_MK, cv_RU
- Missing few more SSE string routine ifuncs. This can be also
regarded as a plus since there are probably still some bugs
lingering within, but it means SUSE won't be part of the testing
process...
Upsides:
- 2.11 stable branch is getting a lot more bugfixes than 2.12 stable
branch, therefore it should be less buggy and this gap will still
widen over time
- 2.11 is also better tested
- Easier maintenance for me ;-)
Does anyone have an opinion either way?
And when would be the last suitable moment for glibc-2.13 entering
Factory?
Thanks,
--
Petr "Pasky" Baudis
The true meaning of life is to plant a tree under whose shade
you will never sit.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
In factory, installing pullin-msttf-fonts-11.4-1.8 doesn't trigger the
installation of the MS TTFs. There is a line
Recommends: fetchmsttfonts
in the RPM but this script seems to be missing.
Werner
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hello,
I'll send a SR to include patch2mail in Factory in some minutes.
Some information about the package according to
http://en.opensuse.org/openSUSE:How_to_contribute_to_Factory :
> the name and purpose
patch2mail is a small script that sends a mail to root if new patches
are available. It runs via cron.daily.
On the technical side, it uses "zypper --xmlout lu -t patch" and
xsltproc to make the output human-readable.
> how long has it been around?
It's in the Contrib repo since 11.2, and has been in my home repo
before. Since some days, it's also in system:packagemanager which will
be the devel project.
patch2mail supports all zypper versions since openSUSE 10.2 (as long as
you build for the respective release), but in practise this won't help
you much for the no longer supported releases ;-)
In theory the 11.1 package should also work for SLES 11, but I never had
a SLES installation available to test it.
> how well has it been tested?
Since it consists only of a small script and some XSLT, there isn't too
much to go wrong ;-)
Changes in the commandline parameters or XML format of zypper are the
only exceptions (both happened already in older distribution releases).
That said: Well-tested on 11.3 and older, not yet tested in Factory by
me because I'm still on 11.3. As long as the zypper interface didn't
change, it will also work in Factory.
> what is the upstream project?
"project" is a big word for 16 lines of shell script and 120 lines of
XSLT ;-) but basically I am also the upstream developer.
I'll announce new versions etc. in my blog - http://blog.cboltz.de or
http://blog.cboltz.de/plugin/tag/patch2mail if you want only articles
about patch2mail.
> does it have a track record of security issues?
No :-)
> what is the purpose of having it in the distribution?
It is a useful tool for servers (where you don't have a desktop to show
the update applet ;-) to inform the admin when new updates (to be exact:
patches) are available.
> who are its users?
Administrators of servers - and of any system you don't use personally
(for example if you have to maintain some desktops in the office).
> what is the license?
GPL 2 or later
Regards,
Christian Boltz
--
"What, you don't think "insmod emacs" is a good idea?" -- Joe Moore
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
On Fri, Nov 19, 2010 at 1:14 PM, Nelson Marques <nmo.marques(a)gmail.com> wrote:
>
> Hi,
>
> Though I'm not an expert, I would probably recommend you to install
> spec-cleaner from Vincent Untz home[1] project and run it on the spec
> file.
I've now done and am building the result on my "unstable" home repo.
>
> Additionally I would also consider you to check out if mint slab menu
> is to use with GNOME, if so... You might want to try to submit request
> it to GNOME:Apps, and eventually sign the opensuse-gnome mailing list.
MintMenu is primarily used on GNOME, but can be used anywhere (like I
said in my OP, I've used it in it's own window on FluxBox and
OpenBox). If it fits better as a GNOME app, I can submit it there.
>
> There are a couple of stuff you can improve on the spec... the
> %find_lang macro is one of the things that pop into sight.
I was unfamiliar with the %find_lang macro until rpmlint started
complaining about it the .mo files not being in %lang. In fact I
didn't worry about localisation in general until on of the users I
have wanted it translated into Spanish. I pulled in the translations
from Linux Mint, but all of their translations are in one package and
distributed as one tarball (so I have to pare that list down into just
mintMenu translations). What I ended up with is admittedly kludgey,
but works and does not make rpmlint complain. In the end what I
really need is a good example on how to appropriately use %find_lang
and %lang; I tried googling but didn't see any real examples, mostly
unanswered questions on how to use it or errors people were getting.
Will
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi, I innocently updated a very old libraw1394 a month and a half ago,
realizing that a lot depended on it I was careful to try not to break
the system but it seems it was like cleaning a mark on the wall to find
out that the wall was rotten under the paint layer. I'm assuming that
VoIP telephony isn't messed with because it just works but all of the
associated software, with the exception of h323plus and GNOME:Factory
opal (VoIP) which has updated to the latest since the libraw1394 update.
I don't know the state of the other telephony apps that use libraw1394
but I'm pretty sure that any package that fails due to a missing
libraw1394.so.8 is depreciated.
Anyway this has come back to haunt me and I'm creating the package
libraw1394-8 to prevent a sudden loss of telephony packages, it's not as
easy as I thought, I have to move the headers in the devel package into
a named directory to prevent a conflict with libraw1394-devel.
IMHO the VoIP packages need an overhaul so any help will be appreciated
- home:plater libraw1394-8, I'm slowly getting snowed under and although
I learn rapidly by finding things out by trial and error this time I
need some more experienced help to speed the process up.
Thanks
Dave P
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi,
I've been preparing Firefox 4 since quite some time in mozilla:beta (and
previously :alpha) and I run it everywhere meanwhile.
The initial Firefox roadmap said it would have been ready by october
this year but was slipped to something "early 2011"
https://wiki.mozilla.org/Firefox/4/Beta
which would still fit into the openSUSE 11.4 release.
There are still some issues and quite some not updated extensions but to
get proper testing I think it makes sense to go for Firefox 4 in Factory
soon.
My plan is to do the update before Milestone 5 (actually right after
milestone 4 to get a feeling before M5 gets done).
I do _not_ plan to have an easy fallback to Firefox 3.x in Factory but
it will be available in the mozilla repository as always. The reasons are:
1. it's extra work to have a package available for parallel installation
2. the much more important one: There is always a risk for user profiles
when doing major downgrades.
Please tell me if there are strong arguments not to do it this way.
Wolfgang
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
I've been packaging mintmenu (for both SUSE and Fedora) for a while on
my own using my home project on OBS. I'd now like to go about getting
it included in the openSUSE repositories.
For those that don't know, mintmenu is the default menu from Linux Mint,
it's written in python and distributed under GPLv2. While it's uses
pygtk, and is primarily used in gnome, it can be used in other desktop
environments also (I've used it in it's own window with OpenBox and
FluxBox). It provides a list of favorite applications, as well as a
searchable menu of installed applications.
I love using mintmenu over the alternatives and believe that other users
would enjoy it as well, if it were installable from official channels.
I'm unsure, however, which devel project I should submit it to. Any
help in getting the ball rolling would be helpful.
My home project:
https://build.opensuse.org/project/show?project=home:unamanic
Closest thing to upostream:
tarballs:
http://packages.linuxmint.com/pool/main/m/mintmenu/
git:
https://github.com/linuxmint/mintmenu
Thanks in advance,
Will
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi,
I noticed that all my modules built for factory currently fail with:
RPM build errors:
File not:
found: /usr/src/packages/BUILDROOT/r8168-8.020.00-1.1.i386/lib/modules/Updating-
xen
File must begin with "/": 2.6.36-18
Which doesn't make much sense to me since I, naturally, don't have a %files
section in my .spec. Examples are e.g. the stuff in "drivers:nic".
Is that a bug or was there some change regarding how to build kernel modules?
regards,
Stephan
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org