Hello!
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 ->
build package.
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 :)
Regards
Krzysztof Lichota (Polish KDE translation team)
Hi,
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
(file:/srv/ftp/opensuse/distribution/SL-OSS-factory/inst-source/)
1: [x] SUSE LINUX Version 10.0.42
(ftp://ftp4.gwdg.de/pub/opensuse/distribution/SL-OSS-factory/inst-source)
2: [x] SUSE LINUX Version 10.0.42
(http://you.novell.hu/i386/10.1/SUSE-Linux10.1-Beta1-Extra/)
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?
Cheers,
--
Liviu Damian
Mobile phone: +40 741 226993
URL: http://liviudm.blogspot.com
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
hi,
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
Loading cache...
Updating cache...
############################################################## [100%]
Computing transaction...
error: Can't install subversion-1.3.0-2@i586: no package provides
libaprutil-1.so.0
Also apache2 does not install (no libapr1 < 2.0).
Happens with beta1 and beta2.
Am I missing something here?
marvin
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:
art-sharp2
gnome-vfs-sharp2
gtkhtml-sharp2
rsvg-sharp2
And for gtk-sharp 1.0.10:
art-sharp
gda-sharp
gnomedb-sharp
gtkhtml-sharp
rsvg-sharp
If you're using gtk-sharp-complete or gtk-sharp2-complete in
neededforbuild, you won't need any changes (thanks Rudi!).
Wade
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Everyone,
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?
Regards,
Lemuel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD1MOqjqd6S/FOPpQRAlGtAKCZ3PmCtzvRBKn0bnt+etFVNk1j1gCdGKN1
ZTEh7IFsjdEmLUAW5BsC6iw=
=zM5T
-----END PGP SIGNATURE-----
(This is a report of a pre-10.0 article from internal list).
Hi folks,
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
and runtime.
Technical Details:
==================
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:
char buf[10];
strcpy(buf,"Hello world!");
now generates warnings like:
xx.c:5: warning: call to __builtin___strcpy_chk will always overflow destination buffer
and runtime errors like:
./xx
*** 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.
Current Status:
===============
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.
Packager TODOs:
===============
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++
code.
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).
Ciao, Marcus
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
in /usr/share/<package>/...?
Below a list with files, perhaps it helps tp detemine the location?
./etc/kolab/amavisd/templates/en_US/charset
./etc/kolab/amavisd/templates/en_US/template-dsn.txt
./etc/kolab/amavisd/templates/en_US/template-spam-admin.txt
./etc/kolab/amavisd/templates/en_US/template-spam-sender.txt
./etc/kolab/amavisd/templates/en_US/template-virus-admin.txt
./etc/kolab/amavisd/templates/en_US/template-virus-recipient.txt
./etc/kolab/amavisd/templates/en_US/template-virus-sender.txt
/etc/kolab/templates/amavisd.conf.template
./etc/kolab/templates/clamd.conf.template
./etc/kolab/templates/cyrus.conf.template
./etc/kolab/templates/DB_CONFIG.slapd.template
./etc/kolab/templates/fbview.conf.template
./etc/kolab/templates/freebusy.conf.template
./etc/kolab/templates/freshclam.conf.template
./etc/kolab/templates/httpd.conf.template
./etc/kolab/templates/httpd.local.template
./etc/kolab/templates/imapd.conf.template
./etc/kolab/templates/imapd.group.template
./etc/kolab/templates/kolab.conf.template
./etc/kolab/templates/kolab_smtpdpolicy.conf.template
./etc/kolab/templates/ldap.conf.template
./etc/kolab/templates/ldapdistlist.cf.template
./etc/kolab/templates/ldaptransport.cf.template
--
Richard Bos
Without a home the journey is endless
(repost from internal mail from yesterday, i have removed only internal
mailingaddresses referenced).
Hi folks,
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
heuristics:
- 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:
--param ssp-buffer-size=8
- full (-fstack-protector-all)
The wrapper will be generated for all functions.
Performance loss:
There will be some small performance loss (due to the approx 6
instructions added).
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,
multimedia.
- Might be used for local privilege escalation.
Ciao, Marcus
dcraw
mDNSResponder
rrdtool
webalizer
libopensync
libsyncml
gaim-otr
novell-openwbem-authenticator
novell-openwbem-authorizer
novell-provider-base
openwbem
id3v2
hal
snort
abiword
avahi
banshee
beagle
dia
epiphany-extensions
epiphany
evince
evolution
f-spot
gaim-galago
gaim
galeon
gdk-pixbuf
gedit
gobby
gpdf
gtk2
inkscape
libsoup
libsvg-cairo
libsvg
liferea
NetworkManager
obby
poppler
xchat
sim
grip
libvisual
libvisual-plugins
ppp
pure-ftpd
qpopper
vsftpd
xntp
konversation
hp2xx
hplip
hp-officeJet
imlib2
kdegraphics3
kdegraphics
kdenetwork3
kdenetwork3
kipi-plugins
koffice-wordprocessing
ktorrent
libkexif
libextractor
openh323
pwlib
sfftobmp
cups-backends
cups-drivers
cups
foomatic-filters
lynx
unace
licq
unarj
unrar
xli
zoo
pdftohtml
libmng
pam_krb5
libexif
freetype2
freetype2
uim
xine-lib
gnokii
kismet
tcpdump
openslp
curl
cron
mutt
pcre
wget
irssi
net-snmp
gd
giflib
id3lib
ImageMagick
ImageMagick
jpeg
libpng
libpng
libtiff
libtiff
libwmf
mc
netpbm
netpbm
sox
xpdf
xpdf
novell-ldapext
novell-smash
cvs
librpcsecgss
subversion
OpenOffice_org
OpenOffice_org
dhcpcd
dhcp
dhcp-server
openssl
openvpn
ethereal
exif
exiftool
imgvtopgm
openssh
ufraw
easytag
imlib
zip
cyrus-imapd
cyrus-sasl
pam_ldap
mailman
at
libosip2
libsidplay
arc
exifprobe
fetchmail
gftp
ghostpcl
lha
libsidplay1
gawk
openmotif21-libs
openmotif
imap
gpsdrive
cabextract
freeradius
MozillaFirefox
MozillaThunderbird
seamonkey
dbus-1
libid3tag
libogg
libvorbis
bind
postfix
a2ps
enscript
filters
ghostscript-library
lpdfilter
lpdfilter
man
procmail
texinfo
xv
sylpheed-claws
performace critical perhaps:
mysql
postgresql
apache2
