rsyslog errors on rawhide
by Mike Chambers
I keep seeing the below error when anacron is running..
/etc/cron.daily/epylog.cron:
Invalid syslog format string in /var/log/secure: rsyslogd: [origin
software="rsyslogd" swVersion="3.21.3" x-pid="1779"
x-info="http://www.rsyslog.com"] exiting on signal 15.
Invalid syslog format string in /var/log/secure: rsyslogd: [origin
software="rsyslogd" swVersion="3.21.3" x-pid="1774"
x-info="http://www.rsyslog.com"] restart
I see the error a couple of times in my /var/log/secure file.
--
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302(a)fedoraproject.org
15 years, 8 months
looking for co-maintainers
by Adam Goode
Hi,
My life is about to get very busy (twins on the way), so I want to make
sure I at least have co-maintainers for all (or most) of my packages.
Anyone interested?
escape -- puzzle game
fvwm -- window manager
gkrellm-weather -- plugin for gkrellm
htmldoc -- converts html into ps or pdf
minirpc -- a new RPC library
mlton -- optimizing compiler for Standard ML
vips -- image library, prereq for nip2
nip2 -- non-destructive lazy image editor
Thanks,
Adam
15 years, 8 months
Icons and relative path of comps icons
by Richard Hughes
On the PackageKit mailing list we're discussing dynamic groups and icons
so that the full comps groups can be supported if the client wants the
same menus as in anaconda.
The exact methods and signals we are adding hasn't been decided yet, but
we are making progress as this needs to be cross compatible with all
distros and all group conventions.
It's been proposed we return a absolute path for icon names, which I
think is a bad idea. It does not allow the icons to be themed, and
doesn't seem portable between environments. Icons should be returned as
named icons rather than full paths.
The icons for fedora comps groups are shipped
into /usr/share/pixmaps/comps by the comps-extras package.
gnome-packagekit will by default look in /usr/share/icons/$foo and
also /usr/share/gnome-packagekit/icons/hicolor for named icons.
I really don't want to symlink everything in /usr/share/pixmaps/comps
to /usr/share/gnome-packagekit/icons in the gnome-packagekit rpm, as
kpackagekit won't be able to use these icons and it seems a bodge.
I don't think comps-extras should be installing
into /usr/share/icons/hicolor/24x24/categories as it's not a theme,
although this would fix a lot of problems.
Anyone got any ideas?
Richard.
15 years, 8 months
koji problem
by Zoltan Kota
Hi,
My build of pybliographer for devel yesterday around 21:00 UTC failed
with the result:
"BuildrootError: could not init mock buildroot, mock exited with status
30"
http://koji.fedoraproject.org/koji/buildinfo?buildID=65374
I tried to resubmit the job without success. Is it a buildsys issue or my
fault?
And now I cannot login to Koji, it says:
"Could not establish an encrypted connection with koji.fedoraproject.org
because your certificate has been revoked."
What to do with this? Could anybody help?
Thanks!
Zoltan
15 years, 8 months
Boot speedup with readahead
by Harald Hoyer
Hello fellow Fedora developers,
recently readahead was modified to adapt to system file changes and to start very early in the boot process
via upstart.
I would like to encourage you to test readahead-1.4.5-3.fc10 from rawhide (even possible on F9), which I built
some minutes ago. It may take a day to reach your local mirror.
# yum --enablerepo=rawhide install readahead
or
# yum --enablerepo=rawhide update readahead
With the next reboot readahead-collector runs and collects the information which files are used during the
boot process. The next reboot then, readahead read ahead those files and the boot process (from init start to
gdm login screen) should be approx. 10% faster.
Hope it speeds up your boot process a little bit. Please report any changes in your boot time (can be measured
with a stop clock or bootchart).
You can modify /etc/sysconfig/readahead to turn readahead on/off.
15 years, 8 months
Strange multilib conflict
by Adrian Reber
Maybe somebody from this list can see the problem in this bug report,
because I am out of ideas:
https://bugzilla.redhat.com/show_bug.cgi?id=462125
A user is installing libcdio on rawhide and gets a file conflict on the
man pages when installing the x86_64 and i386 version at the same time.
I fixed it on my F8 test system and verified it by installing the libcdio
version from rawhide on that F8 system.
On the system of the bug reporter it still fails with the same error
message about a file conflict.
I think I have verified that the man pages in the x86_64 and i386
version of the package have the same time. If somebody knows why this
still fails or if there are any other ideas how to fix this, I would be
happy to hear it. Thanks.
Adrian
15 years, 8 months
Re: Pseudo-locales for i18n testing by English speakers
by Asgeir Frimannsson
----- "Sean Flanigan" <sflaniga(a)redhat.com> wrote:
> Ulrich Drepper wrote:
> > Sean Flanigan wrote:
> >> Would there be any interest in getting something like this into
> glibc?
> >
> > Hell, no. There is no room for testing code in the runtime.
>
<snip>
> Is the implementation of "fetch translations from MO files under
> /usr/share/locale/" hard-coded? If there's already a nice
> programmatic
> hook I could use, even better. If I could register locale-specific
> overrides of gettext(), I could add any number of dynamically
> generated
> locales.
It is set by bindtextdomain().
Somewhat related, look at a previous discussion relating to Ubuntu's patched glibc for supporting language-packs:
http://sources.redhat.com/ml/libc-alpha/2005-03/msg00105.html
> A gettext() hook could also be used to fetch translations from other
> sources, such as a shared, up-to-date, translation database. I think
> that has the potential to be useful to a lot of people, not just
> developers and testers.
>
> It doesn't really make sense to generate thousands of pseudo PO
> files,
> and compile them into static MOs, when all the required data (ie
> English
> text) is available at runtime.
>
> Let me change my question then. How would people feel about having a
> hook to override the behaviour of gettext() in a system-wide fashion?
I guess you could experiment with LD_PRELOAD for this. Tim Foster experimented with this a while a go.
http://blogs.sun.com/timf/entry/how_much_translation_do_you
cheers,
asgeir
15 years, 8 months
GNUstep
by Scott Christley
Greetings,
I'm new to Fedora and am interested in helping get GNUstep included
into Fedora. I'm one of the original developers of GNUstep but have
long since moved up into user space, so I have the ulterior motive
that I can get my own free software research tools (which depend on
GNUstep) packaged into Fedora too some day!
Anyways, I discovered that the topic has come up recently and the
discussion summarized in Fedora weekly news:
http://fedoraproject.org/wiki/FWN/Issue140#GNUstep_Filesystem_Layout_Disc...
so I've read through the emails and tried as much as I could to
understand the issues related to the GNUstep directory structure
fitting with the FHS. I'm not an expert in FSH, so don't think I can
say straight out what I think the best solution, but I offer some
opinions.
Development using GNUstep can produce a number of different products,
the core ones being:
tools
libraries
applications
frameworks
bundles
Now tools and libraries are well-known concepts, a tool is a command-
line program typically self-contained, and a library is a binary
object with some header files. The other products are different in
that they are wrappers for a directory structure and a set of files.
Applications are graphical programs, frameworks are library wrappers
and bundles are executable code to be dynamically loaded at runtime.
They are wrappers because there are many files involved, take an
application, beside the executable object it has files for GUI
elements, configuration, localized strings, localized GUI elements,
images, sounds, other media, etc. etc., all kinds of resources as they
are called. A sophisticated application could easily have hundreds of
such resource files, frameworks and bundles can have any set of
resources files as well.
So my suggestion would be:
* tools mostly but also sometimes libraries can have clear role
outside GNUstep, so it is appropriate to treat them as such. My
suggestion would be FHS and flattened, so that they get install in
expected places like ${_bindir} and %{_libdir}.
* let applications, frameworks and bundles live within the pure
GNUstep layout.
I'm sure I didn't touch on many of the issues that were brought up, so
I look forward to your comments!
cheers
Scott
15 years, 8 months
preUpgrade F9->F10 on LVM snapshot
by Ahmed Kamal
Hi everyone,I wanna help by testing F10 on my laptop. I am currently running
F9 perfectly fine. Here's what I want to do:
- Take a lvm snapshot of my F9 (if that won't work, make a new LV and dd
over the file system)
- boot that .. preUpgrade that into F10 beta (or rawhide). Does preUpgrade
see F10 beta by itself ?
- Post back the results
Since that is not the "usual" upgrade path to say the least, I just want to
know if you guys see any caveats or hoops ? Is that LVM remerging work now
in F10, i.e. if I work with a snapshot and it upgrades fine, can I merge it
back into the "real" LV?
15 years, 8 months
Rawhide booting troubles (plymouthd)
by Konstantin Ryabitsev
With the latest rawhide, I get:
could not start boot splash: No such device
/bin/plymouthd: symbol lookup error: /bin/plymouthd: undefined symbol:
ply_answer_new
I can still boot if I select "Fedora-Base" or another older entry from
the grub screen. In fact, there are the following entries in
grub.conf:
title Fedora (2.6.27-0.382.rc8.git4.fc10.i686)
root (hd0,0)
kernel /vmlinuz-2.6.27-0.382.rc8.git4.fc10.i686 ro
root=/dev/protee_vg/root_lv rhgb quiet
initrd /initrd-2.6.27-0.382.rc8.git4.fc10.i686.img
title Fedora (2.6.27-0.352.rc7.git1.fc10.i686)
root (hd0,0)
kernel /vmlinuz-2.6.27-0.352.rc7.git1.fc10.i686 ro
root=UUID=5956dd1c-1eab-4487-91ca-e4c3bbc0fee6 rhgb quiet
initrd /initrd-2.6.27-0.352.rc7.git1.fc10.i686.img
title Fedora-base (2.6.27-0.352.rc7.git1.fc10.i686)
root (hd0,0)
kernel /vmlinuz-2.6.27-0.352.rc7.git1.fc10.i686 ro
root=UUID=5956dd1c-1eab-4487-91ca-e4c3bbc0fee6 rhgb quiet
initrd /initrd-2.6.27-0.352.rc7.git1.fc10.i686.img
If it helps, I installed 10-Beta and upgraded in place to rawhide.
Replacing root=/dev/protee_vg/root_lv with the UUID as in earlier
entries doesn't make any difference.
Cheers,
--
Konstantin Ryabitsev
Montréal, Québec
15 years, 8 months
