common-lisp-controller for Fedora
by Anthony Green
I've created a draft Feature page on the wiki to copy Debian's
common-lisp-controller package and methodology for installing Common
Lisp implementations and libraries.
http://fedoraproject.org/wiki/Features/CommonLispController
This will require changes to all common lisp implementations in Fedora,
so I'm looking for support from those packagers (some of whom are on copy).
Also, this is not something I can do on my own. I'm hoping there are
like-minded people out there that are interesting in making Fedora a
great platform for deploying Lisp based infrastructure. So, are there
any willing to help over the next 6 months?
Thanks!
AG
16 years, 3 months
[pm] Resume hooks not run
by Leo
Hi there,
We I leave my computer inactive until it goes into suspension, the wake
up from the suspension usually fails i.e. it hangs. I have to shut down
the computer by holding the power button. This is tested in a Dell 700m
Laptop.
You can see from the file pm-suspend.log after one of such a failure
that there was no resume hooks being run.
,----[ pm-suspend.log ]
| Sun Nov 18 00:19:57 GMT 2007: running suspend hooks.
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/00clear =====
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/01grub =====
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /etc/pm/sleep.d/02hardisk =====
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/05led =====
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/10NetworkManager =====
| ===== Sun Nov 18 00:19:57 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/20video =====
| kernel.acpi_video_flags = 0
| ===== Sun Nov 18 00:19:58 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/49bluetooth =====
| ===== Sun Nov 18 00:19:58 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/50modules =====
| ===== Sun Nov 18 00:19:58 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/55battery =====
| ===== Sun Nov 18 00:19:58 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/60sysfont =====
| ===== Sun Nov 18 00:19:58 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/65alsa =====
| ===== Sun Nov 18 00:19:59 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/90clock =====
| ===== Sun Nov 18 00:20:00 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/94cpufreq =====
| ===== Sun Nov 18 00:20:00 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/95led =====
| ===== Sun Nov 18 00:20:00 GMT 2007: running hook: /usr/lib/pm-utils/sleep.d/99video =====
| Sun Nov 18 00:20:00 GMT 2007: done running suspend hooks.
`----
BTW,
suspension by selecting "suspend" in the battery drop down menu or
logout dialog can resume properly.
Is there any difference between manually selecting "suspend" and
automatically "suspend" when inactive?
They seem behave differently for no reason.
HTH,
--
.: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :.
Use the best OS -- http://www.fedoraproject.org/
16 years, 4 months
openoffice-pyuno and external python programs
by Zoltan Kota
Hi,
I sent the email below to fedora-devel some time ago; there was no
response. Let's try again with some additional info. :-)
I'm the fedora maintainer of pybliographer. The development version of
pyblio (which I would like to push to the devel repo soon) has the
capability to interact with openoffice through the pyuno component.
(Bibus can do the same.) It can add citations and generate reference list
in the document for example.
The openoffice.org-pyuno package installs uno.py and other files
under /usr/lib/openoffice.org/program/, so with the default installations
and settings importing uno.py from external python programs gives an
import error. Program specific patches could be used probably to add this
'strange' path to pythonpath, but wouldn't be better to make available
these moduls for python at the openoffice level? See below what debian
does.
Any thoughts, ideas?
Zoltan
---------- Forwarded message ----------
Date: Wed, 12 Sep 2007 23:18:19 +0200 (CEST)
From: Zoltan Kota <z.kota(a)gmx.net>
Reply-To: Development discussions related to Fedora
<fedora-devel-list(a)redhat.com>
To: Fedora devel <fedora-devel-list(a)redhat.com>
Subject: openoffice-pyuno and external python programs
Hi,
Files from openoffice.org-pyuno are installed under
/usr/lib/openoffice.org2.0. So, 'import uno' from python gives an import
error. How should we support external programs to use this module? Should
we patch the program to import uno.py from this directory
somehow? Or would be better to change the installation path in the
openoffice.org-pyuno package?
Debian for instance installs
/usr/share/pycentral/python-uno/site-packages/uno.py
/usr/share/pycentral/python-uno/site-packages/unohelper.py
/usr/lib/python2.4/site-packages/pyuno.so
Zoltan
16 years, 4 months
Packaging Starplot and related data files
by Debarshi Ray
I am packaging Starplot (http://starplot.org/) for Fedora and would
like to discuss some license related issues.
The main Starplot program that gets built from
http://starplot.org/downloads/starplot-0.95.4.tar.gz is licensed under
GPLv2+. However, the Starplot data files distributed as
datahttp://starplot.org/data/gliese3-0.95.tar.gz and
http://starplot.org/data/yale5-0.95.tar.gz seem to be under a
"Redistributable, no modification permitted" license.
----
This is what the COPYING says:
NOTE ON STAR DATA FILES
Everyone is permitted to copy and distribute verbatim copies
of this copyright note, but changing it is not allowed.
The Makefile and .spec file of this data set are licensed under the GNU GPL,
of which you should have received a copy with the StarPlot documentation.
The GPL also applies to the text documentation (README, INSTALL) for this data
set, except where it would conflict with the licensing requirements described
below. The GPL does ***NOT*** apply to the star data files enclosed or
generated. The data files in the orig-data directory originate from the
Astronomical Data Center (http://adc.gsfc.nasa.gov) at NASA Goddard Space
Flight Center, and are copyrighted by their respective authors. Upon asking
the ADC about the permissibility of their redistribution, I was told the
following:
Yes, you are free to distribute the files with your program.
Although, we do ask that you acknowledge, your source (the ADC)
and the original authors.
See: http://adc.gsfc.nasa.gov/adc/acknowledge_adc.html
for more information.
My conclusions are that (1) you are free to redistribute the ADC data files.
However, (2) you must not delete any documentation giving credit for the data
files, for example in the README; and (3) the data files must NOT be altered in
any way (without permission of the original authors). Therefore (4) it is NOT
permissible to redistribute the *.stars files which the StarPlot conversion
program creates from the ADC data files. I have confirmed these conclusions
with the ADC.
The above text is Copyright (C) 2000 Kevin B. McCarty.
----
The following copyright notice is found in the README:
COPYRIGHT NOTE
It is safe to redistribute the files in the orig-data directory,
which, as noted above, are freely available on the Astronomical Data Center
web site. However, since these are copyrighted data, you may NOT redistribute
modified versions of them. This is why I have the StarPlot-format data files,
*.stars, generated at install time instead of being available for download.
I would advise that you NOT redistribute these *.stars data files. See the
file COPYING for more information.
----
Can these data files be packaged as starplot-data for Fedora? Please advise.
Thanks,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
16 years, 4 months
Heads up: openssl and gnutls rebase in rawhide
by Tomas Mraz
I have decided to complete the dependency breakage which will be caused
by the openldap update because many packages which depend on openldap
libraries depend also on OpenSSL or GNUTLS. So to spare a few rebuild
cycles I will do openssl and gnutls rebase in sync. There should not be
any API changes so simple rebuild will be sufficient.
I'm still undecided whether we should have a compat package for openssl
in Fedora so if you know any 3rd party software which will be broken by
the openssl libraries SONAME change and which is actively used on
current Fedoras, please let me know.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
16 years, 4 months
SDL pulseaudio workaround hack
by Warren Togami
* Tue Oct 30 2007 Warren Togami <wtogami(a)redhat.com> - 1.2.8-4
- SDL_AUDIODRIVER=esd temporary hack until SDL supports pulseaudio directly
avoids applications from locking up. (#358341)
At the last minute before F-8's release I added this ugly hack to
SDL_mixer to force SDL to use esd for sound instead of the default ALSA.
This change was made because it would at least allow sound on popular
games like wesnoth to work, and make the Fedora Games spin not
dead-on-arrival.
Unfortunately, this had the side-effect that we knew at the time of
disabling SDL sound if you have pulseaudio disabled or removed.
I should have thought of this earlier, but the /etc/profile.d/* scripts
that set the environment variable commanding SDL to use esd could have
been conditional. Still not perfect, but better to tide us over until
Lennart implements native pulseaudio for SDL that he promised to do
before F9.
The following changes should improve our workaround. I am uncertain if
the .csh version needs a matching unset for nonomatch or does it happen
automatically?
Should we push this in a SDL_mixer update?
Warren Togami
wtogami(a)redhat.com
cvs diff: Diffing .
Index: SDL_pulseaudio_hack.csh
===================================================================
RCS file: /cvs/pkgs/rpms/SDL_mixer/devel/SDL_pulseaudio_hack.csh,v
retrieving revision 1.1
diff -u -p -r1.1 SDL_pulseaudio_hack.csh
--- SDL_pulseaudio_hack.csh 31 Oct 2007 14:39:10 -0000 1.1
+++ SDL_pulseaudio_hack.csh 27 Nov 2007 01:33:43 -0000
@@ -1,2 +1,4 @@
# Temporary hack until SDL directly supports pulseaudio
-setenv SDL_AUDIODRIVER esd
+# If alsa-plugins-pulseaudio is installed, force SDL to output sound to esd
+set nonomatch
+if ( -e /usr/lib*/alsa-lib/libasound_module_pcm_pulse.so ) setenv
SDL_AUDIODRIVER esd
Index: SDL_pulseaudio_hack.sh
===================================================================
RCS file: /cvs/pkgs/rpms/SDL_mixer/devel/SDL_pulseaudio_hack.sh,v
retrieving revision 1.1
diff -u -p -r1.1 SDL_pulseaudio_hack.sh
--- SDL_pulseaudio_hack.sh 31 Oct 2007 14:39:10 -0000 1.1
+++ SDL_pulseaudio_hack.sh 27 Nov 2007 01:33:43 -0000
@@ -1,2 +1,3 @@
# Temporary hack until SDL directly supports pulseaudio
-export SDL_AUDIODRIVER=esd
+# If alsa-plugins-pulseaudio is installed, force SDL to output sound to esd
+[ -e /usr/lib*/alsa-lib/libasound_module_pcm_pulse.so ] && export
SDL_AUDIODRIVER=esd
16 years, 4 months
alpha/beta software in Fedora 8?
by Chuck Anderson
Fedora 8 shipped with an BIND 9.5.0a6, recently updated to 9.5.0a7.
The release announcement for BIND says:
BIND 9.5.0a7 is a alpha release for BIND 9.5.0.
This is a technology preview of new functionality to be be
released in BIND 9.5.0. New APIs are not yet frozen.
Is this an appropriate release to be putting in a stable Fedora
release? I've encounted a segfault in this version, which I've
reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=400461
I'm concerned about the policies which allow unstable software in
stable Fedora releases. Is it considered acceptable/encouraged to
have alpha versions of software in the stable release? Is there any
policy?
Thanks.
16 years, 4 months
Severe X breakage heads up
by Adam Jackson
I plan to rebase the X server to git master a week from today (Monday,
November 12), which means the changes should hit rawhide on Tuesday.
DEAR SHORT ATTENTION SPAN PEOPLE:
% sudo sed -i -e '/^\[main\]/ a exclude=xorg-*' /etc/yum.conf
Run that line to opt out of the disaster. Thank you for your time.
Now for some details.
This X server requires libpciaccess. Not all of the drivers have been
ported yet. Not all of them will be ported by Monday, though I'll try
to have the big three of {radeon,intel,nv} and the vesa driver converted
by then. This should cover most people. I hope.
If your driver is not ported, you'll see an error like this in the X
log:
(EE) module ABI major version (1) doesn't match the server's version (3)
This means switch to vesa, or else back down to F8 X.
Mesa will rebase in the same go. This may or may not break 3D for you.
It shouldn't, but it might. Likewise libdrm, but that's unlikely to be
a problem in and of itself. I'm quite likely to update those two
components sometime this week, they should be relatively low impact on
their own.
This server will also introduce input hotplug support. TBH I have no
idea how this should be set up at the moment. I'll try to get something
working at least for the machines I have here, but that might only be
good enough for static configuration same as F8 and earlier. If someone
wants to own the i-h part of this that'd be awesome, otherwise we'll get
to it as we have time.
I think those are the highlights. If there are any further questions,
please ask, I may have missed something. If any bugs come up in the
transition, please do file them! We need to know what breaks so we know
what we need to fix. And of course, all patches and assistance are
greatly appreciated.
- ajax
16 years, 4 months
FLAC 1.2.x may need rebuilds
by Michael Schwendt
The Fedora 8 upgrade from FLAC 1.1.4 to 1.2.0 has broken FLAC file import
in Audacity. A simple rebuild of Audacity fixes it.
All packagers with a dependency on libFLAC* are advised to check whether
they also need to rebuild their packages.
flac 1.2.1-1 : Tue Sep 18 2007
flac 1.2.0-1 : Tue Sep 11 2007
[...]
Fedora 7 most likely is affected, too, due to a FLAC security update
from 1.1.4 to 1.2.1:
flac 1.2.1-1 : Wed Oct 17 2007
16 years, 4 months
Smolt database is broken
by Michael Wiktowy
I just submitted my profile a few days ago and immediately tried to
retrieve it and got some other machine that didn't match my config. So
I submitted it again and things looked a bit more reasonable. Today I
checked it again and the vast majority of it has changed.
So there is some massive database corruption going on AFAICT. Did I
miss a message somewhere indicating this?
ref my machine:
http://smolt.fedoraproject.org/show?UUID=c8dbb9d3-a9bd-4ba6-b92e-4a294ba5...
/Mike
16 years, 4 months