no epiphany.i386 package for Fedora x86_64 ?
by Anuj Verma (Kevin)
Hello,
I use epiphany as my default browser of choice instead firefox. This goes
well on i386 installs of Fedora but on x86_64 installations this becomes
a trouble, if tools like nspluginwrapper are not working fine or if 64bit
JRE plugin is not there yet.
Fedora for x86_64 has a firefox.i386 package for 32bit compatibility,
should epiphany also have epiphany.i386 package in x86_64 repo ?
Kevin
15 years, 6 months
PackageKit Misconceptions
by Richard Hughes
Hi guys.
I've been pointed to the "low-hanging fruit" discussion on this list
by a couple of people. I wasn't on this list, but now am.
So what is PackageKit:
• A daemon that accepts asynchronous jobs.
• A way of letting certain groups of people do stuff to the package
database with a fine grained server-client security model.
• A system service that starts only when needed.
• A way of inhibiting suspend/hibernate/restart/shutdown when
performing actions.
• An interface to a packaging backend.
The fine grained security model allows an installer application to be
loaded as the user (without a root password), to do searches without a
password, and to only ask the user for authentication for any
privileged task, for instance updating the system or installing a
package. This lets the admin decide what level of security is best for
the box in question.
[http://people.freedesktop.org/~hughsient/temp/pk-polkit.png]
A packaging backend can be something in a thread like libapt-pkg (as
it has a C++ binding) or using a polling backend with external helper
scripts for stuff like yum (python) or urpmi (perl) with no C
bindings.
The helper scripts communicate over stdin, stderr and stdout using a
loosly defined (by the backend) protocol, in an effort to make
scripted synchronous operations into async ones with a common DBUS
interface. I've started to define this here:
[http://gitweb.freedesktop.org/?p=users/hughsient/PackageKit.git;a=blob_pl...]
What is Packagekit-gnome:
• An lightweight update applet that runs once per logged in user that
refreshes the cache at startup and displays update status and critical
security warnings.
[http://people.freedesktop.org/~hughsient/temp/pk-updates-warning.png]
• A way of seeing what other users are doing with PackageKit, so you
can see why the hdd light is flashing after doing a fast user switch
somewhere else.
• An application installer. Note, gnome-app-install is probably going
to be the long term target as this will be ported to the PackageKit
API. [http://people.freedesktop.org/~hughsient/temp/pk-application2.png]
So, misconceptions in the thread so far (in my opinion):
Pirut and PackageKit are mutually exclusive:
You can happily run them both side by side. I am now. If pirut is open
then PK should queue the request until pirut is closed.
PackageKit is vapourware:
Nope, I'm running it right now. True, only the dummy backend is
supported but the apt and yum backends are coming on. The deps are
also pretty harsh; you need PolicyKit, dbus-glib, dbus and
PolicyKit-gnome all from git. F8 rpm's for PackageKit are in my repo
[http://people.freedesktop.org/~hughsient/fedora/].
PackageKit API is rubbish:
I know. It's unstable right now, and is changing to fulfill all the
use-cases. My view is you have to let an API evolve to be optimal,
rather than over-engineer everything when the complexities are not
known. [http://people.freedesktop.org/~hughsient/temp/pk-interface.xml]
Error enums will not be powerful enough
Fair enough, I hear you loud and clear. Maybe we can set a hint to the
backend about the locale, but I would have to think about this more.
PackageKit will be included in F9/F10/desktop-spin/crackpot-spin
That's up to you guys. I think it will be some time before the API is
stable, and all the UI and policy bits and bobs are worked out.
PackageKit also needs a security code review as sometimes it's running
as the root user. So, the short story is I'm not pushing this to be
included in fedora right now, as it can only do 10% of what the
current tools can do.
PackageKit allows you to install stuff without a password
Well, it allows the admin to set what sort of authentication you need
to do each action, be it your own password, an admins password, or
just to deny the request.
PackageKit is yet another system daemon to be started at boot time:
Nope, it's started only when needed using system activation, and quits
a few seconds after finishing it's last queued task.
We are just a layer over yum -y --ask-no-questions:
If PackageKit is just a layer, I think the layer allows us to do some
important things the old system could not, and allows us to share code
between distros and desktop projects.
Also, my view is that questions should never be asked. Who has ever
clicked no to "Load GPG key from Fedora Project"? Is there a legal
requirement to show such a warning?
So, I hope that has cleared things up a bit. Comments and suggestions welcome.
Thanks,
Richard Hughes.
15 years, 6 months
no Desktop SIG meeting today
by David Zeuthen
Hi,
There is no meeting today; Matthias is out on vacation, Chris is dealing
with fender bender and the rest of us didn't send out an agenda /
organize it in time. Apologies. We'll meet next week; will be a good
time to reflect on F8t2 and the road ahead bringing us to Fedora 8.
Thanks,
David
15 years, 6 months
Okay earlygdm re-tooled for a desktop spin
by Jon Nettleton
Based on some urging from the community I decided to re-tool what I
had and release a version of patches to it that could use the existing
rhgb without any patches. You can download the svn diff here
http://www.hekanetworks.com/~jnettlet/open-source/fedora/earlygdm.diff
Before you just going and applying this patch to your system here are
the working internals
*!!!!* I have patched start_udev so it can be run in two separate
pieces. So I had the necessary pieces to start X without waiting 7
seconds staring at starting udev *yawn* this was necessary. There is
no reason we can't dupe start_udev into two individual files that
doesn't touch the original file. I am open to doing that.
I don't have init level checking in my code yet. It is simple to do I
just haven't done it yet.
I have gdm reading from a custom earlygdm.conf file so you can mess
with that without changing your systems default behavior.
One other patch just moves the acpi module installation to
/etc/sysconfig/modules . Working the rc.sysinit I just kept seeing
that there and had no idea why were weren't using the mechanism 10
lines above it.
Right now this works seamlessly on my nvidia box, but my openchrome
laptop is killing off the x-server before the gdm greeter has run. My
guess is my laptop is slow enough that it is hitting one of gdm's
timeout values and the slave is getting reset.
Currently the manual fscking and such is not interactive because rhgb
needs another fifo to send input back from it's vte to another
program. I started writing this and then decided to wait until I
found out what other people think. I am also toying with allowing
rhgb to do gtk.embedding, or possibly create an overlay like gdm uses
to run it's setup program, so the apps run in rc.sysinit if it is
unconfigured can run their Xorg counterparts. I am also tempted to
play around with Zenity to see what else we can do to remove the need
for a terminal and give more intuitive dialogs easily.
Jon
15 years, 6 months
livecd hacking
by Colin Walters
I've done some work on the Live CD kickstart images, available here:
http://submind.verbum.org/~walters/livecd.git/
(Until Jeremy returns from vacation and can review patches to be put in
the main livecd git repository)
The most important change so far is to create
"livecd-desktop-minimal.ks" which is then used as a basis for:
livecd-fedora-desktop.ks
livecd-fedora-kde.ks
livecd-online-desktop.ks
Rather than each thing duplicating a lot of code for the livecd init
script, etc.
The online-desktop is just a stub right now while I fix up some issues,
but I've booted the livecd-fedora-desktop successfully
(livecd-desktop-minimal.ks also boots...into twm! Retro.).
Admittedly I haven't tested the KDE one, but moving forward this
unforking should help us to identify changes common between them which
seem like good candidates for comps or Fedora package changes.
Sebastian, since you were the last person to touch the KDE bits, could
you have a look at these changes?
I also added a number of improvements to livecd-creator, the git log has
the gory details.
15 years, 6 months
low-hanging fruit
by Matthias Clasen
As discussed in the meeting, here is my personal
"laundry list" of low-hanging fruit. Note that some of
these are being worked on for F8 anyway.
- enable nss-mdns by default
- clean up emblems in nautilus
- remove obsolete applets
- reconsider default panel config (launchers)
- unlock keyring on login
- use xdg-user-dirs consistently
- disable root login
- get rid of xfs
- get rid of pam_console
- NM by default
- PA by default
- get rid of a bunch of services that we don't need on a
live cd, like nfs/rpc/autofs
- have a close look at the system-config tools we install
- cleaned up artwork packaging
And here are some larger things:
- rethink installation and updates (see hughsie's
recent work)
- desktop background stuff:
slideshows, channels, per-workspace
- no lvm/raid in livecd installer
- good xrandr 1.2 support
- no root user
- replace init system
- new graphical boot
- composited desktop by default
- rethink user account handling:
kiosk mode (?), guest accounts
Matthias
15 years, 7 months
More low hanging fruit.
by Jon Nettleton
Should the desktop release have X run on vt1 and a text console on vt2?
I also don't see much reason to have more than that either. I probably
wouldn't remove them from inittab just disable them in run level 5.
Jon
15 years, 7 months
PA by default
by Bastien Nocera
Heya,
Before Fedora 8, is there a plan to fix a few regressions or integration
issue with PA?
From:
https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01196.html
> You also have to make sure that some GConf keys are set up properly:
>
> /system/gstreamer/0.10/default/audiosrc -> pulsesrc
> /system/gstreamer/0.10/default/audiosink -> pulsesink (or autoaudiosink)
> /system/gstreamer/0.10/default/chataudiosink -> pulsesink (or autoaudiosink)
> /system/gstreamer/0.10/default/musicaudiosink -> pulsesink (or autoaudiosink)
This means that the "Devices" part of the Sound Preferences in GNOME is
pretty useless. I guess there's a PA specific way of changing the
default input and output, but you lose integration with the desktop.
This will also probably break the device selection that the volume
applet uses (it uses the same as the default sound events device, iirc).
I'm also thinking of applications' volume setup. At least Totem and
Rhythmbox have the concept of "system volume" (which is per device, and
they don't touch), and the "application volume" (which they do). Here,
we're adding the "PA volume".
How do we plan on handling that?
Cheers
15 years, 7 months
Idea: easier transition for newcomers from other DEs/OSes
by Martin Sourada
Hi,
It's all about picking default settings new users wish. Imagine a user
who is coming from Windows to Fedora, but he has no clue how linux
works. It would greatly help him if the linux behaved to some extent
similar to Windows - meaning applications look (themes), window's
buttons layout (in this case same), menu layout, keyboard shortcuts etc.
The same for users coming from Mac OS and for users used to Gnome and
switching to KDE and opposite way. The idea is that user selects what he
wants his desktop resemble, and then the usage of the desktop would be
more intuitive to him.
What would we need for that?
1. Check out, how much we can set up GNOME/KDE to look and behave
like other DEs/OSes
2. If some of the stuff which makes this easier is available, but
not in fedora, get it into repository
3. Write a utility that can change the DE's settings to what we
have found in 1.
4. Integrate the utility into anaconda or first boot.
The utility should be pretty straightforward - you will have a bunch of
radio buttons captioned Windows 9x, Windows XP, Windows Vista, Mac OS X
(dunno version differences though, might need more radio buttons for
that one), GNOME, KDE (for how it should look like) and a two check
boxes with simple description of GNOME and KDE (in the description
should be noted primarily differences between those to, to ease
selection to one who has no idea what GNOME/KDE is; for what will be
used as 'backend').
Just a though... Your opinions? Is it even desirable? Does it make
sense?
Martin
15 years, 7 months
Desktop spin: Java browser plugin
by Andrew Overholt
Hi,
With IcedTea set to be in F8, should we look at including the java
browser plugin in the desktop spin by default?
Andrew
15 years, 7 months
