Cannot rely on /dev being present in %post scripts?
by David Woodhouse
According to bug #517013, %post scripts should not assume that /dev is
available -- so we can't do anything that requires the existence of
/dev/null, /dev/urandom, etc.
Is this a known and expected packaging rule, or is it a bug in the way
that the user is attempting to install the packages?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
14 years, 1 month
Suggestions
by Elad
Hello.
First of all: thank you, fedora developers, for making such a great linux
distro.
I think I have some good ideas and suggestions that might help you improve
Fedora:
1) Create a new plymouth theme (or in other words, ask the artwork team to
do so):
The current default plymouth theme is almost the same theme from fedora 11.
I think we need to change it.
2) Plymouth boot splash background should match the gdm background
as I've explained here: https://bugzilla.redhat.com/show_bug.cgi?id=550321
3)Plymouth needs a graphical user interface to select the boot splash
screen, with a preview of the selected theme, so the user wouldn't have to
reboot to see if he likes the theme.
4)
yum should select the mirror to download from in a smarter way, considering
the current load on the mirror and the distance of the mirror from the user.
This will help reduce the load on the mirrors and make the download faster
for the user. The mirrorlist server should know what is the load on each
mirror, and give yum the mirrorlist sorted by the load and the distance from
the user. yum should prefer the less busy and closest mirror it can find.
5)PackageKit UI improvements:
5.1)When downloading packages, display the percentage of the download
progress on the progress bar
5.2)Fix bug #551201 ( https://bugzilla.redhat.com/show_bug.cgi?id=551201)
5.3)Make it possible to undo transactions using gpk-log
6)BiDi problems with translations:
this problem is the most annoying thing in fedora for me. gnome-terminal for
example doesn't have any bidi support. terminals are not supposed to support
BiDi
but the problem begins with applications like pkcon or diff, in which
terminal output is also translated.
that causes unreadable output. e.g if the output was supposed to be שלום it
will display םולש.
there are two ways to fix this problem
1) make gnome-terminal and others support BiDi output
2) put a comment in each POT file that warns the translator about strings
which will be written in the terminal so translators would know what should
be translated
I think the first way is better.
7)Combine all hardware listing programs (e.g hwbrowser, usbview, lshw-gui)
into one, comprehensive, easy to use GUI.
thank you for listening.
-Elad
14 years, 1 month
Fedora Linux Format software review: January 2010
by Christopher Brown
Hi folks,
Linux Format is a popular magazine in the U.K but which ships all over
the world. It regularly reviews interesting bits of software and I
thought:
a) It would be interesting to see how much of what they review is
included in Fedora
b) It would be a good idea to get that which is not in and/or up to date
c) If there is enough interest I would like to form a SIG to do the
monthly reviews - a kind of packaging wishlist on steroids perhaps :)
I blogged about this recently and you can read the basic idea there:
http://chruz.wordpress.com/2009/12/23/ive-got-the-music-on-my-radio/
The editor has expressed his willingness to send details of software
which they will review to us so we have a head start. I have conducted
the first review of the January 2010 issue which you can read here:
https://fedoraproject.org/wiki/LinuxFormatPackaging
There are some interesting omissions, for example Recoll, the desktop
search tool which came out ahead of Beagle and Google Desktop and
which doesn't even have a review request opened for it yet.
A few points that need mentioning:
1) I do not and have never worked for Linux Format nor has anyone I know :)
2) There may be some glaring errors - this is why this is on the wiki
so please feel free to update/change etc. For example I have not
undertaken rigorous reviews for the software's suitability.
3) This is not intended as anything other than a distillation of what
would be good to have in the repositories.
I welcome your comments as ever.
--
Christopher Brown
14 years, 2 months
Update on packages violating the Static Library guidelines
by Michael Schwendt
Bugzilla status for packages violating the Static Library guidelines:
acl 556036 -> CLOSED
atlas 556037
attr 556038 -> CLOSED
audit 556039
binutils 556040
brltty 556041
Canna 556034 -> CLOSED
cdparanoia 547682
comedilib 556043
dnssec-tools 556044
e2fsprogs 545144
expat 556046
fftw2 556047
file 556048 -> CLOSED
gcc 556049
gdbm 556050
ghostscript 556051 -> CLOSED
gnutls 556052 -> CLOSED
gpsim 556053
gtk+extra 556054
hpic 556055 -> CLOSED
isdn4k-utils 556056
js 556057 -> CLOSED
ldns 556058 -> CLOSED
libaio 556059 -> CLOSED
libannodex 556060
libbtctl 556061
libcaca 556062
libcddb 556063 -> CLOSED
libcdio 556064
libcmml 556065
libdnet 556066
libevent 556067
libftdi 556068 -> CLOSED
libnl 556069
liboggz 556070
libotr 556071
librx 556072 -> CLOSED
libsemanage 556073 -> CLOSED
libsndfile 556074
libstatgrab 556075
libtranslate 556076
libtwin 556077
libuninameslist 556078 -> CLOSED
libxslt 556079
link-grammar 556080
linux-atm 556081
linuxwacom 556082
lockdev 556083 -> CLOSED
meanwhile 556084
mpich2 545149
munipack 556086
nfs-utils-lib 556087
numactl 556088
opencdk 556089
openldap 556090 -> CLOSED
proj 556091
python 556092 -> CLOSED
QuantLib 556035 -> CLOSED
rubberband 556093
shapelib 556094
syck 556095
sysfsutils 556096 -> CLOSED
texlive 556097
torque 556098
util-vserver 556099
xbsql 556100 -> CLOSED
xen 556101
xfsprogs 556102
xmlsec1 556103
--
Michael Schwendt
Fedora release 12 (Constantine) - Linux 2.6.31.12-174.2.3.fc12.i686.PAE
loadavg: 0.10 0.05 0.01
14 years, 2 months
ABRT frustrating for users and developers
by Christoph Wickert
I know that APRT is still very young technology, but after 2 months it's
time for a interim conclusion. For me the conclusions are:
Pro:
* abrt is a help for developers: I received one positive feedback
from a developer: The backtrace looks "interesting" but cannot
be fixed without a major rewrite of the app.
* abrt helps to fix bugs sometimes: So far abrt helped me to fix
three crashes in two apps (in Fedora and upstream).
Con:
* Unfortunately 3 out of ~ 40 reports is not a good percentage.
* As already pointed out by Michael Schwendt some time ago, there
were some good traces in the beginning but then they became
unusable. Starting with abrt 1.0.2 it got better again but I
still get bogus reports sometimes.
* As a maintainer abrt causes a lot of work. You have to respond
to the tickets, ask for details, explain how to install
debuginfo manually and tell people that their
* abrt is frustrating for maintainers: Upstream refuses to accept
the backtraces generated by abrt. Happened to me three times.
* abrt is frustrating for users: Today I received my first "No
need for a reply...I will stop submitting tickets."
Can somebody confirm my observations?
Regards,
Christoph
14 years, 2 months
berlios.de compromised since 2005
by Seth Vidal
Hi folks,
This lwn article reports that berlios.de has been compromised for a long,
long time.
http://lwn.net/Articles/369633/
So I compiled a little list of pkgs that need a look:
http://skvidal.fedorapeople.org/misc/berlios-pkg-owners-list.txt
Here is the list as well:
arbiter:slim:http://slim.berlios.de/
athimm:freenx-client:http://freenx.berlios.de/
athimm:freenx-server:http://freenx.berlios.de/
ausil:oooqs2:http://segfaultskde.berlios.de/index.php?content=oooqs2
awjb:gimmix:http://gimmix.berlios.de/
bjohnson:unpaper:http://unpaper.berlios.de
bouska:wifi-radar:http://wifi-radar.berlios.de/
caolanm:mythes-es:http://openthes-es.berlios.de
dmaphy:graphem:http://graphem.berlios.de/
dnglaze:openocd:http://openocd.berlios.de/web/
drago01:hardinfo:http://hardinfo.berlios.de/
drago01:pinot:http://pinot.berlios.de/
dwmw2:bcm43xx-fwcutter:http://bcm43xx.berlios.de/
fab:python-wifi:https://developer.berlios.de/projects/pythonwifi/
hguemar:sonata:http://sonata.berlios.de/
hubbitus:sim:http://sim-im.berlios.de/
isimluk:ruby-ncurses:http://ncurses-ruby.berlios.de/
ixs:bitbake:http://developer.berlios.de/projects/bitbake/
jamatos:python-cpio:http://developer.berlios.de/projects/python-cpio/
jcollie:radiusclient-ng:http://developer.berlios.de/projects/radiusclient-ng/
jreznik:kio-ftps:http://kasablanca.berlios.de/kio-ftps/
jspaleta:gpodder:http://gpodder.berlios.de/
kkofler:kio_gopher:http://kgopher.berlios.de/
kwizart:atmel-firmware:http://at76c503a.berlios.de/
kwizart:tslib:http://tslib.berlios.de/
laxathom:soundconverter:http://soundconverter.berlios.de/
limb:netpanzer:http://netpanzer.berlios.de
limb:wavextract:http://developer.berlios.de/projects/wavextract
mgarski:smb4k:http://smb4k.berlios.de/
michaelc:scsi-target-utils:http://stgt.berlios.de
mtasaka:mirage:http://mirageiv.berlios.de/
musuruan:hatari:http://hatari.berlios.de/
oget:canorus:http://canorus.berlios.de/
oget:jjack:http://jjack.berlios.de/
oron:libhocr:http://hocr.berlios.de
ovasik:star:http://cdrecord.berlios.de/old/private/star.html
rdieter:kasablanca:http://kasablanca.berlios.de/
rdieter:lensfun:http://lensfun.berlios.de/
rishi:libgringotts:http://gringotts.berlios.de/
rjones:ocaml-pgocaml:http://developer.berlios.de/projects/pgocaml/
rvokal:net-tools:http://net-tools.berlios.de/
silfreed:gpsd:http://developer.berlios.de/projects/gpsd/
spot:lincity-ng:http://lincity-ng.berlios.de/
stingray:cuetools:http://developer.berlios.de/projects/cuetools/
sundaram:gimmage:http://gimmage.berlios.de/
terjeros:cpipe:http://developer.berlios.de/projects/cpipe/
terjeros:python-tidy:http://utidylib.berlios.de/
till:fatsort:http://fatsort.berlios.de/
twaugh:pyusb:http://pyusb.berlios.de/
vcrhonek:fetchmail:http://fetchmail.berlios.de/
if you're on this list then you need to talk to upstream and find out if
they have done an audit yet. You might consider doing an audit yourself,
if you have the background to know what sort of things to look for.
thanks,
-sv
14 years, 2 months
ABRT useful for this user
by Stephen John Smoogen
I just wanted to say thanks to the guys who integrated ABRT into F12.
It has rough edges and I know it needs improvement, but I have filed
more 'bugs' than in many past releases where instead I just let things
slide. Most of the items I have run into have been fixed and I have
tried to help the engineers who have asked for info.
Thankyou.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
14 years, 2 months