Re: System Config Tools Cleanup Project - tools to eliminate/replace
by chasd
> * system-config-display
There are still cases ( corner cases, granted ) where the no-
xorg.conf-auto-foo doesn't quite work, and s-c-d gets you to a better
working X. I muck with xorg.conf so rarely I forget the directives
and syntax between each time - editing by hand is painful.
When using older monitors that don't have the talkie-talkie to tell
the graphics card what resolution it supports, choosing a model from
the list in s-c-d gets a list of resolutions known to work. s-c-d
makes it much easier to switch between drivers to see which one
better supports what is in your machine.
The KMS drivers kinda made s-c-d more useful, I hadn't needed it for
a while.
Matthew Woehlke :
> Bill pointed out that this is not installed by default, which is fine.
> I'd say we should keep it that way; available and working for those
> that
> need it, but not installed by default.
Puts s-c-d in maintenance limbo.
It might already be in that position.
> * system-config-httpd
Is this why the apache config file(s) don't more closely match
upstream ?
I'm the opposite of s-c-d here, I know the httpd.conf directives from
memory,
I don't need a GUI to help me, plus I don't run X on the systems that
run httpd.
Instead of editing httpd.conf ( the old apache 1.3.x way ), it should
add or subtract whole files in /etc/httpd/conf.d
--
Charles Dostale
System Admin - Silver Oaks Communications
15 years, 2 months
Experience and observations of F11a/rawhide so far
by Keith G. Robertson-Turner
Surprisingly stable, for the most part, but with a few nasties:
. RPM broke completely at one point (md5 mismatch errors), necessitating
manual extraction from an RPM of updated components. Was there a more
graceful way of handling the changeover?
. Radeon driver and kernel modesetting. This has been coming on in leaps
and bounds, but it's still not quite there yet. The stock F11a kernel
had no support, then there was support but it caused visual
corruption, now it seems to work properly (2.6.29-0.252.rc8.fc11) but
the radeon driver subsequently causes the system to lock hard when
running anything OpenGL related (drm?). That final point was the cause
of the next...
. ext4 data loss. It's been many years since I lost an entire filesystem
in normal operation, and that was not under Linux, but it happened
yesterday after the aforementioned lockup. I had to hard reset, but
the worst I expected was a journal recovery. Not so. In this case, the
kernel first insisted there was no space left on the device (whereas
there was actually over a 100GB), then another reboot later it failed
to grok the filesystem at all, claiming it did not appear to be an
ext4 filesystem. I can't say whether or not this is related to the now
well publicised delayed allocation issue, or whether this will be
resolved in the fixes promised for 2.6.30, but it has definitely put
me off ext4 ... for now. Maybe I'll come back to it in a few years. I
would question the prudence of pushing this as a visible anaconda
option in the final release though, since some are undoubtedly bound
to accept it as ready for production, and IMHO it isn't.
. Speed issues. I noticed no discernible improvement in disk access
speed (no benchmarks, just my impression), and the graphics subsystem
was dog slow, but this was probably just an expected result of the
current state of radeon. Booting seemed slightly faster, although
maybe that was a purely psychological effect of being distracted by
Plymouth? I seem to recall timing a cold boot at 60 seconds to the
login prompt, which is OK for a 5400RPM EIDE laptop drive, but not
stunning. IIRC I get that now on the currently installed Fedora 8
(2.6.26.8-57.fc8). Overall, the system felt decidedly laggy.
. Compatibility issues. The newly pushed Thunderbird 3 reintroduced an
age-old problem with saving draft copies on an IMAP directory (hangs
forever). I can't remember what I did to fix it last time, but nothing
obvious worked this time around. Naturally, my huge collection of
plugins no longer work (something which seems to happen even with the
most minor update, and which I find intensely irritating), most
crucially the Enigmail plugin, which seems to lack any compatible
update (64 bit system). I did grab one which looked like it was
supposed to work, but plugin manager complained about the build being
incompatible (gcc issue?). That's a blocker for me, since I absolutely
must have GPG support, so I had to revert back to Thunderbird 2.
. Suspend/Hibernate ... broken again. I must admit this really confuses
me. If it works once, then why shouldn't it always work? Very, very
annoying.
. Pulseaudio stuttering and proper device control ... It's quite funny
seeing mplayer suggest that my 2GHz AMD64 system, with Audigy 2 audio,
"might not be fast enough" to play media. The "tsched=0" setting does
help somewhat, but this really needs to be addressed. Another issue is
the lack of equaliser controls (bass/treble) which is provided by the
DSP on the card. I really want to see more than just "Master" when I
open volume control. No, seriously, I really, really do. A post
elsewhere from one of the devs, suggested that equaliser controls
should "never be part of the software", which I found to be a rather
arrogant position, since how else is one supposed to control the
equaliser settings on a pair of headphones connected to a laptop,
especially when the card actually provides this function in the
hardware? I spent a few minutes trying to hack support in using
something called swh and ladspa, but whatever this is supposed to do
it didn't work here - either that or I just failed to grasp the
incredibly convoluted and confusing Pulseaudio configuration settings.
This is something that really needs to be built in. No human should
ever need to endure the torture of Pulseaudio's dotfiles. Until PA can
actually play audio without stuttering, and provide the same degree of
device control as ALSA (easily), then I'm afraid I won't be using it.
Ending on a positive note ... radeon, when it actually worked, was
highly impressive. I found no discernible difference in 3D speed between
it (under F11a) and the proprietary fglrx (under F8), although I'm sure
a more empirical benchmark would have revealed a difference in numbers.
It gives me real hope that fully accelerated Free Software 3D graphics
drivers are now actually a reality.
As for everything else, well it's still early days yet, but my overall
impression is "OK", nothing more. Plymouth stands out in my mind as a
compelling motive, along with various improvements to libgpod - which
are unavailable to older releases due to a cascade of unresolvable deps,
and I have become rather enamoured with KDE4.2, so I suppose this may be
the release that finally compels me to dump F8. I just hope some of the
above issues are addressed by the time it goes public.
One request I would like to throw out there, as a RFE, is the ability to
specify *keyfiles* instead of a password, when anaconda is setting up an
encrypted filesystem with cryptsetup. My current arrangement requires me
to manually edit the initrd thus:
echo Setting up disk encryption: SecureKeys
cryptsetup luksOpen /dev/sdb1 SecureKeys
mkdir /SecureKeys
mount -t ext3 /dev/mapper/SecureKeys /SecureKeys
echo Setting up disk encryption: takeMScrypt
cryptsetup luksOpen /dev/sda2 takeMScrypt
--key-file=/SecureKeys/takeMScrypt.key
echo Closing encryption keys volume: SecureKeys
umount /SecureKeys
cryptsetup luksClose SecureKeys
sda is a USB keychain, with a built in MicroSDHC card reader.
sda1 is "/boot", unencrypted.
sda2 is "/" on an LVM volume encrypted with the kefile on sdb1.
sdb is a MicroSDHC card, with the key store on sdb1, which is itself
password encrypted.
So when this boots, I'm asked for a password once, which unlocks the key
store, and uses keyfiles in that key store to unlock the other
filesystems, then closes and unmounts the keystore, so the MicroSDHC
card can be physically removed (and possibly hidden).
How easy would it be to build something like this into anaconda?
Thanks for listening.
--
Regards,
Keith G. Robertson-Turner
15 years, 2 months
error from ant script
by subhodip biswas
hi!
While trying to package JOSM which is java based and uses ant to compile.
ant when called from rpmbuild fails to compile the code saying :
------
static import declarations are not supported in -source 1.4
[javac] (try -source 1.5 to enable static import declarations)
------
However executing ant separately on source leads to successful compilation.
----
What am i missing?
--
Regards
Subhodip Biswas
GPG key : FAEA34AB
Server : pgp.mit.edu
http://subhodipbiswas.wordpress.com
http:/www.fedoraproject.org/wiki/SubhodipBiswas
15 years, 2 months
pkgconfig can't find libgnomeui on F9
by Braden McDaniel
I have a package (openvrml) that's failing to build on F-9:
http://koji.fedoraproject.org/koji/getfile?taskID=1254875&name=build.log
The build log indicates that the pkg-config check for libgnomeui is
failing. In configure.ac, that check looks like:
PKG_CHECK_MODULES([GNOMEUI], [libgnomeui-2.0 libgnome-2.0 >= 2.14], ,
[have_gnomeui=no])
The specfile does have:
BuildRequires: libgnomeui-devel >= 2.14
This is succeeding for F-10 and devel; and it *used* to work for F-9.
Why would it be failing now?
--
Braden McDaniel e-mail: <braden(a)endoframe.com>
<http://endoframe.com> Jabber: <braden(a)jabber.org>
15 years, 2 months
Re: Full Licence field
by Kevin Kofler
Simon Schampijer wrote:
> So, the point to ship a license per package is fine. I actually did not
> want to relax that. I had the technical problem to need to access the
> license field to be able to display it in a dialog inside Sugar.
>
> http://shell.sugarlabs.org/~erikos/licence_field.png
>
> And since - the file is placed in different places on each distro I
> wanted to see if a common place would be possible, makes sense. On
> Fedora this could have been in addition to the per package license
> field. Not very economic of course.
FWIW, KDE does exactly that.
/usr/share/kde4/apps/LICENSES/ (where /usr/share/kde4/apps is the KDE 4
application data directory, it can vary from distribution to distribution)
contains the following files (owned by kdelibs):
ARTISTIC BSD GPL_V2 GPL_V3 LGPL_V2 LGPL_V3 QPL_V1.0
The KAboutData class in kdelibs provides an enum which allows you to pick
one of these licenses. If the license is not one of those, the application
is responsible for loading the exact text of the license explicitly.
> Anyhow - while thinking about it, I was not even sure the displaying of
> the full license is correct/needed - or matches the guidelines. For
> example I have not seen something similar in GNOME.
KDE does it. (Try "Help / About (application name)" in a KDE application.
The name of the license is a link, clicking that link opens a dialog box
with the full text of the license.)
It's not a bad idea, but it isn't strictly needed either. (There are plenty
of GPLed applications which don't display the full text of the GPL in the
UI.)
Kevin Kofler
15 years, 2 months
Re: Full Licence field
by Kevin Kofler
Simon Schampijer wrote:
> Yes. So the main question is now if Fedora would be willing to ship
> general licenses under /usr/share/common-licenses, I think.
FWIW, I don't think it's legal to do that, licenses need to accompany the
package.
But in any case what really matters is whether RH Legal thinks it's legal,
not whether you or me do.
Kevin Kofler
15 years, 2 months
rawhide report: 20090324 changes
by Fedora compose checker
Compose started at Tue Mar 24 06:01:04 UTC 2009
Removed package libgnomedbmm
Removed package monodoc
Removed package oki4linux
Updated Packages:
anaconda-11.5.0.36-1
--------------------
* Mon Mar 23 2009 David Cantrell <dcantrell(a)redhat.com> - 11.5.0.36-1
- Add EFI, Apple Bootstrap, and PPC PReP Boot formats. (dlehman)
- Remove all implicit calls to self.format.destroy from Device classes.
(dlehman)
- Pop the busy cursor when we're done with the wait window (#491736).
(clumens)
- If the new size and old size are the same, treat as a no-op (#491496).
(clumens)
- Let mountFilesystems handling bind mounting /dev (#490772). (clumens)
- Not all FileDevices have parents, so don't assume. (clumens)
- Bind mount formats are mountable. (clumens)
- If a filesystem is already mounted, don't raise an error. (clumens)
- Fix a typo calling the superclass's constructor. (clumens)
- Add a fake device for bind mounting /dev. (clumens)
- If there was an exception leading to the urlgrabber error, log it.
(clumens)
- Fix the import of checkbootloader (#491574). (clumens)
- Add a missing import (#491605). (clumens)
gdm-2.26.0-6.fc11
-----------------
* Fri Mar 20 2009 Ray Strode <rstrode(a)redhat.com> - 1:2.26.0-6
- Fix problem in keyboard layout selector (483195)
gnome-screensaver-2.26.0-1.fc11
-------------------------------
* Thu Mar 19 2009 Matthias Clasen <mclasen(a)redhat.com> - 2.26.0-1
- Update to 2.26.0
k3d-0.7.11.0-1.fc11
-------------------
* Sun Mar 22 2009 Denis Leroy <denis(a)poolshark.org> - 0.7.11.0-1
- Update to upstream 0.7.11.0
* Wed Mar 04 2009 Denis Leroy <denis(a)poolshark.org> - 0.7.10.0-1
- Update to upstream 0.7.10.0
- Build system now based on cmake
- All patches upstreamed or obsoleted
- Added potfiles file list patch fix
- Removed example subpackage
- Removed packaged bitstream fonts, use Fedora ones instead
* Wed Feb 25 2009 Fedora Release Engineering <rel-eng(a)lists.fedoraproject.org> - 0.6.7.0-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
parted-1.8.8-15.fc11
--------------------
* Mon Mar 23 2009 Joel Granados <jgranado(a)redhat.com> - 1.8.8-14
- Correct the behavior of upated_mode functions when the ASSERT fails (thx to hansg).
pyparted-2.0.9-1.fc11
---------------------
* Mon Mar 23 2009 David Cantrell <dcantrell(a)redhat.com> - 2.0.9-1
- Upgrade to pyparted-2.0.9
Summary:
Added Packages: 0
Removed Packages: 3
Modified Packages: 6
Broken deps for i386
----------------------------------------------------------
gdal-1.6.0-4.fc11.i386 requires libodbc.so.1
gdal-1.6.0-4.fc11.i386 requires libodbcinst.so.1
gdal-1.6.0-4.fc11.i386 requires libhdf5.so.5
gdal-perl-1.6.0-4.fc11.i386 requires libodbc.so.1
gdal-perl-1.6.0-4.fc11.i386 requires libodbcinst.so.1
gdal-perl-1.6.0-4.fc11.i386 requires libhdf5.so.5
gdal-ruby-1.6.0-4.fc11.i386 requires libodbc.so.1
gdal-ruby-1.6.0-4.fc11.i386 requires libodbcinst.so.1
gdal-ruby-1.6.0-4.fc11.i386 requires libhdf5.so.5
grass-6.3.0-10.fc11.i386 requires libodbc.so.1
libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
mapnik-0.5.2-0.10.svn780.fc11.i386 requires dejavu-fonts-sans
pfstools-imgmagick-1.7.0-3.fc11.i386 requires libMagickCore.so.1
pfstools-imgmagick-1.7.0-3.fc11.i386 requires libMagick++.so.1
pfstools-octave-1.7.0-3.fc11.i386 requires libhdf5.so.5
xastir-1.9.5-2.fc11.i386 requires libMagickCore.so.1
Broken deps for x86_64
----------------------------------------------------------
gdal-1.6.0-4.fc11.i386 requires libodbc.so.1
gdal-1.6.0-4.fc11.i386 requires libodbcinst.so.1
gdal-1.6.0-4.fc11.i386 requires libhdf5.so.5
gdal-1.6.0-4.fc11.x86_64 requires libhdf5.so.5()(64bit)
gdal-1.6.0-4.fc11.x86_64 requires libodbcinst.so.1()(64bit)
gdal-1.6.0-4.fc11.x86_64 requires libodbc.so.1()(64bit)
gdal-perl-1.6.0-4.fc11.x86_64 requires libhdf5.so.5()(64bit)
gdal-perl-1.6.0-4.fc11.x86_64 requires libodbcinst.so.1()(64bit)
gdal-perl-1.6.0-4.fc11.x86_64 requires libodbc.so.1()(64bit)
gdal-ruby-1.6.0-4.fc11.x86_64 requires libhdf5.so.5()(64bit)
gdal-ruby-1.6.0-4.fc11.x86_64 requires libodbcinst.so.1()(64bit)
gdal-ruby-1.6.0-4.fc11.x86_64 requires libodbc.so.1()(64bit)
grass-6.3.0-10.fc11.x86_64 requires libodbc.so.1()(64bit)
libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
mapnik-0.5.2-0.10.svn780.fc11.i386 requires dejavu-fonts-sans
mapnik-0.5.2-0.10.svn780.fc11.x86_64 requires dejavu-fonts-sans
pfstools-imgmagick-1.7.0-3.fc11.x86_64 requires libMagick++.so.1()(64bit)
pfstools-imgmagick-1.7.0-3.fc11.x86_64 requires libMagickCore.so.1()(64bit)
pfstools-octave-1.7.0-3.fc11.x86_64 requires libhdf5.so.5()(64bit)
xastir-1.9.5-2.fc11.x86_64 requires libMagickCore.so.1()(64bit)
Broken deps for ppc
----------------------------------------------------------
gdal-1.6.0-4.fc11.ppc requires libodbc.so.1
gdal-1.6.0-4.fc11.ppc requires libodbcinst.so.1
gdal-1.6.0-4.fc11.ppc requires libhdf5.so.5
gdal-1.6.0-4.fc11.ppc64 requires libhdf5.so.5()(64bit)
gdal-1.6.0-4.fc11.ppc64 requires libodbcinst.so.1()(64bit)
gdal-1.6.0-4.fc11.ppc64 requires libodbc.so.1()(64bit)
gdal-perl-1.6.0-4.fc11.ppc requires libodbc.so.1
gdal-perl-1.6.0-4.fc11.ppc requires libodbcinst.so.1
gdal-perl-1.6.0-4.fc11.ppc requires libhdf5.so.5
gdal-ruby-1.6.0-4.fc11.ppc requires libodbc.so.1
gdal-ruby-1.6.0-4.fc11.ppc requires libodbcinst.so.1
gdal-ruby-1.6.0-4.fc11.ppc requires libhdf5.so.5
grass-6.3.0-10.fc11.ppc requires libodbc.so.1
libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
mapnik-0.5.2-0.10.svn780.fc11.ppc requires dejavu-fonts-sans
mapnik-0.5.2-0.10.svn780.fc11.ppc64 requires dejavu-fonts-sans
pfstools-imgmagick-1.7.0-3.fc11.ppc requires libMagickCore.so.1
pfstools-imgmagick-1.7.0-3.fc11.ppc requires libMagick++.so.1
pfstools-octave-1.7.0-3.fc11.ppc requires libhdf5.so.5
xastir-1.9.5-2.fc11.ppc requires libMagickCore.so.1
Broken deps for ppc64
----------------------------------------------------------
cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7
gdal-1.6.0-4.fc11.ppc64 requires libhdf5.so.5()(64bit)
gdal-1.6.0-4.fc11.ppc64 requires libodbcinst.so.1()(64bit)
gdal-1.6.0-4.fc11.ppc64 requires libodbc.so.1()(64bit)
gdal-perl-1.6.0-4.fc11.ppc64 requires libhdf5.so.5()(64bit)
gdal-perl-1.6.0-4.fc11.ppc64 requires libodbcinst.so.1()(64bit)
gdal-perl-1.6.0-4.fc11.ppc64 requires libodbc.so.1()(64bit)
gdal-ruby-1.6.0-4.fc11.ppc64 requires libhdf5.so.5()(64bit)
gdal-ruby-1.6.0-4.fc11.ppc64 requires libodbcinst.so.1()(64bit)
gdal-ruby-1.6.0-4.fc11.ppc64 requires libodbc.so.1()(64bit)
grass-6.3.0-10.fc11.ppc64 requires libodbc.so.1()(64bit)
libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
mapnik-0.5.2-0.10.svn780.fc11.ppc64 requires dejavu-fonts-sans
pfstools-imgmagick-1.7.0-3.fc11.ppc64 requires libMagick++.so.1()(64bit)
pfstools-imgmagick-1.7.0-3.fc11.ppc64 requires libMagickCore.so.1()(64bit)
pfstools-octave-1.7.0-3.fc11.ppc64 requires libhdf5.so.5()(64bit)
xastir-1.9.5-2.fc11.ppc64 requires libMagickCore.so.1()(64bit)
15 years, 2 months
WANTED: Clever solution for Transifex storage
by Ignacio Vazquez-Abrams
So here's the scoop.
Right now, a stock install of the transifex package
creates /var/lib/transifex. This directory and everything beneath it is
currently owned by root:root. What needs to happen is that it needs to
be read/written by whatever is running Transifex, be that as a
standalone Django app, via httpd, or some other HTTP server. Frankly, I
got nothing. Anyone else have any ideas?
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
15 years, 2 months
Developer UI for PackageDB
by ranjith kannikara
I name is Ranjith Babu Kannikara. I am a pre-final year student in
govt.Engg College Thrissur, kerala(india). I have been learning
c,python,and their APIs for quite good amount of time. And Java and
Lisp as of now. I have little experience in working with some large
code-base from the last year GSOC in which I have worked with the Zope
Foundation in project 'Porting Zope2 to python2.5' .
My GSOC proposal is for making the PackageDB Developer UI more
flexible and friendly for the developers so that It wont waste the
valuable time of the developer. The present Developer UI is outdated
and needs serious changes and some additional options that will make
it easy to handle the acls, within much lesser time and with much less
effort. And it implemented by including more check boxes and buttons and
by setting reminders for works to be done.
The ideas are listed in detail in the wiki page
https://fedorahosted.org/packagedb/wiki/NewDevUI
The works to be done over the project have a flow like this..
* Aggregating the options that are to be there in the UI.
* Arranging the options with check boxes and buttons instead of select
boxes.
:- ie arranging the options in rows and coloumns with each rows
start with a user and the check boxes/buttons in
the row contains the permissions that can be given to the user.
:- if there is more choice of permissions for each user then
checking itself will be annoying then there will be some
extra coloumns( 2 or 3 ) of check boxes corresponding to each
user like 'give full permissions' 'give minimal
permissions' and a custom set .
:- these boxes, as their names indicate, will automatically give
checkings in a set of boxes the developer may define
a custom set if he find himself giving a set of permissions
together quite often.
( I can make a picture of how the UI will be like after the
summer, and it will be easy for me if I could get the other
options than 'Approve' and 'Awaiting for review' )
* After the list of the users a button to add new user can be given
which will expand to a text box on click. And this check box will
automatically search and match the text with the names in the list
user as it is entered in the box. ( Implementing such a button and
text box wont be difficult with javascript ).
* Such a button can be provided for the co-maintainer/watcher or the
button it will be enough to provide provisions in the first button it
self to make the new user co-maintainer/watcher once a new user is
added.( All these work belongs to the UI and it will not be difficult
when each button are defined to perform the background works for these
options assigned to them.
* In the page, Toshio have given (https://admin.fedoraproject.org/
pkgdb/packages/name/python), we can see links to bug reports, package
status etc. Another link named ' Active Requests' can be added there
which will refer to a page that lists the active requests. The
requests can also be arranged so that it can be handled within no time
but this needs me to get an idea about the possible requests a
developer can get.
* As the requests are being listed it is easy to track what happens to
the request and and if a request is being left unnoticed or in some
state of waiting this track can be used to get the list of requests
that needs sending remainders. ( Here i need some more help from some
one else to generate the automatic reminders)
* As our implementation of the new UI will be much like a new
Interface with either the background or the existing page itself as
background for the new UI. In such way of implementation it will be
easy to show the respective EOL only and give options to switch in
between them.
Awaiting your reply
Ranju
--
http://www.ranjithkannikara.blogspot.com/
15 years, 2 months
