I am not a packager, but a translator. Maybe my problem is already
solved, but I have never heard of anything like this. If so, point me
into the right direction :)
My main problem is that Suse (and any other Linux distribution) cannot
be fully used by person not knowing English, because package summaries
and descriptions are in English. So, I would like to draw your attention
to incorporating translation into process of creating and building packages.
How I imagine it:
1. Translators are used to using .po (gettext-style) files. There are
many tools for updating such files, translation, automated checking,
etc. These files contain text to translate (in English) and
corresponding translated text.
2. rpm has ability to specify translated summary and description in
.spec file and tools (such as Yast package manager) can extract it from
binary RPM file and show it to user. The main problem is how to update
the spec file with translation (while allowing updates of
summaries/descriptions and updates of translations). This is why it has
to be done during creating packages (I don't know of any tool which
would allow updating translation in already built RPM file, but maybe it
could be created).
3. There are already tools in KDE which allow extracting text to
translate from .desktop files (into .po files) and update back .desktop
files with translation. I think it could be also done with .spec files
(I can even volunteer to write a script to do that). So the process
would be .spec -> .po -> translator updates translation -> .spec ->
4. Now the main problem is creating infrastructure to do this - some
kind of repository of .po files for packages which can be accessed by
translators, and which will be used when building packages.
5. I also see other problems - when Yast package manager fetches
information about packages from packages source, it shouldn't fetch
descriptions in all languages but in one (to save bandwidth). So maybe
translations should not be incorporated in RPM files but distributed
separately? I am not sure my proposal is the best (putting translations
in RPM files), so maybe you come up with something better :)
Anyway, I would like to start the discussion on this matter as I think
it is very important for average users :)
Krzysztof Lichota (Polish KDE translation team)
I want to make some packages for SUSE Linux 10.1 Beta1. First thing I've
done was to install y2pmsh, and create the additional profiles for
10.1. Unfortunately it seems some packages aren't available:
package libselinux is not available.
package c_compiler is not available.
package mozilla-devel is not available.
package avahi-compat-howl is not available.
package avahi-compat-howl-devel is not available.
package ilbc is not available.
package ilbc-devel is not available.
package silc-toolkit is not available.
package silc-toolkit-devel is not available.
Here are my installation sources:
0: [x] SUSE LINUX Version 10.0.42
1: [x] SUSE LINUX Version 10.0.42
2: [x] SUSE LINUX Version 10.0.42
I can't use build because it stops when searches for libselinux
(..................can not find libselinux.rpm... exit.).
Any advice or idea about how can I make RPMS for Beta1?
Mobile phone: +40 741 226993
As I mentioned in my blog today, I've packaged up gstreamer010-ffmpeg.
I'm going to create a gstreamer010-complete meta-package tomorrow, this
will include gstreamer010, plugins-base, plugins-good, plugins-bad,
plugins-ugly, gstreamer010-python and gstreamer010-ffmpeg.
James Ogley james(a)usr-local-bin.org
Packages for SUSE: http://usr-local-bin.org/rpms
Make Poverty History: http://makepovertyhistory.org
seems that there is no package which provides libaprutil-1.so.0. I got an
error while trying to install subversion.
ws:~ # smart install subversion
error: Can't install subversion-1.3.0-2@i586: no package provides
Also apache2 does not install (no libapr1 < 2.0).
Happens with beta1 and beta2.
Am I missing something here?
More sub packages have been split out. This should have been done the
first go around, but better now than later.
The following packages have been added:
And for gtk-sharp 1.0.10:
If you're using gtk-sharp-complete or gtk-sharp2-complete in
neededforbuild, you won't need any changes (thanks Rudi!).
-----BEGIN PGP SIGNED MESSAGE-----
The package information for 'php5' with openSuSE 10.0 says that it includes
the "... PHP binary (CLI) ..." (/usr/bin/php5), however, running
$ php5 -v
says it's cgi:
PHP 5.0.4 (cgi) (built: Sep 13 2005 02:24:00)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies
This makes some command line scripts behave differently (due to the difference
with the way CGI and CLI handle paths), like PEAR's PHPUnit2, which we need
to use for unit testing our applications.
The 'php4' package, however, has the correct version of the binary--the CLI.
Can we also have the CLI version with the 'php5' package?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
-----END PGP SIGNATURE-----
(This is a report of a pre-10.0 article from internal list).
The gcc 4 introduction brings fortunately some enhancements in
regards to better checks for security problems.
One of them is light weight buffer overflow checking during compile
If the C compiler define -D_FORTIFY_SOURCE=x is specified
(x can be 1 or 2 currently), special versions of "memcpy", "strcpy",
"sprintf", "gets", and so on are defined and compiled differently,
so that code like this:
now generates warnings like:
xx.c:5: warning: call to __builtin___strcpy_chk will always overflow destination buffer
and runtime errors like:
*** buffer overflow detected ***
Those errors of course need to be fixed.
This checking method can only detect overflows if the destination buffer
size is known at compile time.
The performance impact of this method is low.
Introduced with 10.0 snapshot 2 we are now using "-D_FORTIFY_SOURCE=2" as
default in the RPM_OPT_FLAGS.
We have fixed all problems we found in the buildsystem already.
However, this requires the following from you:
* Make sure that strcpy, memcpy and friends are not implicitly defined.
If you see this warning:
"implicit declaration of function #strcpy#"
it will not detect those simple buffer overflows.
To fix such cases, include the standard header: <string.h>
(for *printf warnings, <stdio.h>)
* Make sure your package uses RPM_OPT_FLAGS for compiling C and C++
There is still a number of package that does not do this.
I have run a heuristics (grep ;) over all our autobuild logfiles
to find such offenders.
The logfile seperated by maintainer is in: <internalpath>
the full warnings logfile is at <internalpath>
NOTE! There might be reasons you can't use RPM_OPT_FLAGS,
or that only matches for package internal buildtools where found.
These are cases where the heuristic failed.
This is no official endorsement of RPM_OPT_FLAGS (yet).
I have a whole bunch of template files, where to place/locate template files?
Is this /etc/<package>/... or would it be better to put those
Below a list with files, perhaps it helps tp detemine the location?
Without a home the journey is endless
(repost from internal mail from yesterday, i have removed only internal
We decided to offer and use an additional method of stack overflow protection
for the next products.
We are currently using the "Fortify Source" lightweight buffer overflow
checking (you will know the -D_FORTIFY_SOURCE=2 defines that get used
by autobuild). I explained it in my previous mail.
With gcc 4.1 there is an new additional method of stack overflow detection.
It was formerly called "ProPolice" or "Stack Smash Protection (SSP)"
but is now usually refered to as "Stack Protector".
It protects against stack based buffer overflows using following
- On function entry a canary ("Kanarienvogel") is put onto the stack.
(Canary in tribute to the canary birds that early coalminers took
into the mines to detect poisonous gases ... when the canaries die
they still had time to leave.)
x86 generated code:
mov %gs:0x14,%eax (fetch random canary from TLS)
mov %eax,0xffffffec(%ebp) (store on stack)
xor %eax,%eax (clear value)
- On function exit the canary is compared with the value on the stack.
If it is no longer the same, the program is aborted.
x86 generated code:
mov 0xffffffec(%ebp),%edx (retrieve canary from stack)
xor %gs:0x14,%edx (xor against original value, if same
it will be 0 (equal))
jne ....aborting... (if not equal ... jump to abort)
... normal return assembler code...
- The code will change the order of variables on the stack to put
character arrays on top of the stack.
This avoids overwrite of other function variables by stack overflows
of character arrays which might go undetected by this protector otherwise.
This checking code can be enabled in two modes:
- normal (-fstack-protector)
In this mode it will use a heuristic to determine the functions that
need the above wrapper.
The current heuristic is "uses a character array at least 8 byte long"
This number of bytes can be changed by using this compiler option:
- full (-fstack-protector-all)
The wrapper will be generated for all functions.
There will be some small performance loss (due to the approx 6
But the number of functions with characters arrays is usually
limited and not in the fast path.
I have two apps already compiled with -fstack-protector:
gaim has 76 functions out of 2022 instrumented.
ethereal has 141 functions out of 1973 instrumented.
What YOU need to do:
If you think your application or library might have stack buffer
overflows, you can add it to your global optflags.
I have created a list of suggested RPMs to instrument, generated
by the following criteria:
- Had security updates in the last years.
- Processes input got from the network, especially pdf, images,
- Might be used for local privilege escalation.
performace critical perhaps: