devel November 2007

devel@lists.stg.fedoraproject.org

350 participants
427 discussions

common-lisp-controller for Fedora
by Anthony Green 03 Jan '08

03 Jan '08

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

4 10

[pm] Resume hooks not run
by Leo 21 Dec '07

21 Dec '07

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/

2 1

openoffice-pyuno and external python programs
by Zoltan Kota 17 Dec '07

17 Dec '07

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

3 7

Packaging Starplot and related data files
by Debarshi Ray 17 Dec '07

17 Dec '07

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

4 10

Heads up: openssl and gnutls rebase in rawhide
by Tomas Mraz 14 Dec '07

14 Dec '07

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

5 9

SDL pulseaudio workaround hack
by Warren Togami 12 Dec '07

12 Dec '07

* 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

3 3

alpha/beta software in Fedora 8?
by Chuck Anderson 10 Dec '07

10 Dec '07

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.

37 102

Severe X breakage heads up
by Adam Jackson 08 Dec '07

08 Dec '07

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 35

FLAC 1.2.x may need rebuilds
by Michael Schwendt 07 Dec '07

07 Dec '07

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

2 2

Smolt database is broken
by Michael Wiktowy 05 Dec '07

05 Dec '07

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-4a294ba5a9… /Mike

12 19

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2007