[arch-dev-public] GNOME 2.28 roadmap
At this moment we have a gnome-unstable repository, containing GNOME 2.28.0. This repository should be used on top of testing, though I'm working on it to make it compatible with just extra. Todo: - Compile packages against extra depends, not testing - Update some packages, make both architectures identical - Drop PolicyKit from hal, use at_console rules instead - Port remaining policykit-enabled packages to polkit - Drop PolicyKit completely, switch to polkit - Rebuild remaining packages for gmime 2.4 - Look for issues with poppler 0.12, possible rebuilds ahead - Try to track down required rebuilds because of changed dependencies and split packages When my todo-list above here is finished, I'll make an announcement about it. I would like to open it for public testing and allow bugs to be filed in flyspray. I don't want to drag this update through testing because of the huge size: most mirrors already have these packages, and dragging it through testing means just another resync of packages for every mirror. The main packaging changes in this release: - Use devicekit-disks for volume management - Use devicekit-power for power management - Drop hal support from the disk backend in libgphoto - Move from PolicyKit to polkit - Update gdm to 2.28. - Drop esound from the dependency tree - Build with -Wl,--as-needed, remove unneeded dependencies - Use the webkit backend for epiphany. Gecko is no more - Split libsoup into libsoup and libsoup-gnome
On Thu, Oct 1, 2009 at 6:47 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
At this moment we have a gnome-unstable repository, containing GNOME 2.28.0. This repository should be used on top of testing, though I'm working on it to make it compatible with just extra.
Todo: - Compile packages against extra depends, not testing - Update some packages, make both architectures identical - Drop PolicyKit from hal, use at_console rules instead - Port remaining policykit-enabled packages to polkit - Drop PolicyKit completely, switch to polkit - Rebuild remaining packages for gmime 2.4 - Look for issues with poppler 0.12, possible rebuilds ahead
There'll definitely be rebuilds for poppler. my TeXLive install pdf export broke. I havn't had a chance to file a bug or even investigate which package yet - sorry, very busy week. James
James Rayner schrieb:
There'll definitely be rebuilds for poppler. my TeXLive install pdf export broke. I havn't had a chance to file a bug or even investigate which package yet - sorry, very busy week.
Hrm, pdf export is back when you run all the suggested commands from the texlive post-upgrade: texconfig-sys rehash updmap-sys --quiet --nohash --syncwithtrees fmtutil-sys --all At least that solved it for me.
On Thu, 2009-10-01 at 21:21 +1000, James Rayner wrote:
On Thu, Oct 1, 2009 at 6:47 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
At this moment we have a gnome-unstable repository, containing GNOME 2.28.0. This repository should be used on top of testing, though I'm working on it to make it compatible with just extra.
Todo: - Compile packages against extra depends, not testing - Update some packages, make both architectures identical - Drop PolicyKit from hal, use at_console rules instead - Port remaining policykit-enabled packages to polkit - Drop PolicyKit completely, switch to polkit - Rebuild remaining packages for gmime 2.4 - Look for issues with poppler 0.12, possible rebuilds ahead
There'll definitely be rebuilds for poppler. my TeXLive install pdf export broke. I havn't had a chance to file a bug or even investigate which package yet - sorry, very busy week.
James
Pdftex needs a patch to work with 0.12, a user mailed me with patches.
To give a status update here: - Gtk2 has been updated to 2.18.1 and was built against libcups from extra. Testing shouldn't be a requirement anymore, as the remaining libraries moved to core already. - Architectures are mainly identical now, only gtkmm is ahead on x86_64 I've done some investigation about the rest of the todo list: - KDE doesn't support polkit in the current shape. Fedora compiles KDE without policykit to get rid of PolicyKit 0.9x. I think we should do the same - Poppler remained ABI stable in its bindings, the only package that I could find broken with poppler 0.12 is texlive-bin, which needs a patch to actually compile I hope to get some time for this the upcoming weekend. If anyone has different views on KDE and PolicyKit, please let me know.
Am Dienstag 06 Oktober 2009 10:29:58 schrieb Jan de Groot:
- KDE doesn't support polkit in the current shape. Fedora compiles KDE without policykit to get rid of PolicyKit 0.9x. I think we should do the same
I don't think so; afaik policykit is nonoptional and will break stuff. So why can't we keep policykit? -- Pierre Schmitz, http://users.archlinux.de/~pierre
Am Dienstag 06 Oktober 2009 10:38:53 schrieb Pierre Schmitz:
nonoptional
To clrafiy this: it might be possible to build KDE without policykit with loss of functionality and we sould need to drop some packages like shaman and k3b. -- Pierre Schmitz, http://users.archlinux.de/~pierre
On Tue, 2009-10-06 at 10:57 +0200, Pierre Schmitz wrote:
Am Dienstag 06 Oktober 2009 10:38:53 schrieb Pierre Schmitz:
nonoptional
To clrafiy this: it might be possible to build KDE without policykit with loss of functionality and we sould need to drop some packages like shaman and k3b.
This is the fedora discussion: http://www.linux-archive.org/fedora-development/358521-policykit-0-9-going-a... Their KDE project meeting about it: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-01 Another related bug: https://bugzilla.redhat.com/show_bug.cgi?id=519674 It appears the only authorization agent at this moment is the one provided by polkit-gnome, so the "OnlyShowIn" should not be limited to GNOME only as stated by the bugreport.
On Tue, 2009-10-06 at 11:16 +0200, Jan de Groot wrote:
On Tue, 2009-10-06 at 10:57 +0200, Pierre Schmitz wrote:
Am Dienstag 06 Oktober 2009 10:38:53 schrieb Pierre Schmitz:
nonoptional
To clrafiy this: it might be possible to build KDE without policykit with loss of functionality and we sould need to drop some packages like shaman and k3b.
This is the fedora discussion: http://www.linux-archive.org/fedora-development/358521-policykit-0-9-going-a...
Their KDE project meeting about it: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-01
Another related bug: https://bugzilla.redhat.com/show_bug.cgi?id=519674
It appears the only authorization agent at this moment is the one provided by polkit-gnome, so the "OnlyShowIn" should not be limited to GNOME only as stated by the bugreport.
Looking further, there's a polkit1 branch of polkit-qt, though it's far from complete. This is what KDE has to say about Polkit1: http://techbase.kde.org/Polkit-Qt-1 As we'll lock out software from our distribution if we remove policykit now, I think it's best to keep policykit for KDE. When KDE 4.4 is released, I think it's safe to remove and use polkit instead. Plans as we have them now are to remove PolicyKit 0.9 support from anything that isn't KDE related. This means that GNOME will lose the authorization agent and the policykit settings gui. As policykit is only used by KDE applications when GNOME 2.28 comes into the repositories, I don't see a problem using the KDE tools for that.
On Tue, 2009-10-06 at 10:38 +0200, Pierre Schmitz wrote:
Am Dienstag 06 Oktober 2009 10:29:58 schrieb Jan de Groot:
- KDE doesn't support polkit in the current shape. Fedora compiles KDE without policykit to get rid of PolicyKit 0.9x. I think we should do the same
I don't think so; afaik policykit is nonoptional and will break stuff. So why can't we keep policykit?
The reason why KDE depends on policykit is because it provides an authorization agent and settings manager for it. I don't know if KDE uses policykit more than that, but at least it's optional. As for policykit being required: K3B uses it for k3bsetup. Why I don't like having two versions of policykit: it's confusing. I remember people shouting about policykit being shit because they don't understand it, how about having two versions of policykit, with two configurations? Fedora 12 ships without the old policykit, and they ship KDE 4.3 also, so it's possible to build without policykit 0.9. The only difference between them and us is that we ship an early alpha version of K3B that requires it, while they ship the stable version.
participants (4)
-
James Rayner
-
Jan de Groot
-
Pierre Schmitz
-
Thomas Bächler