Tom spot Callaway wrote: Would using something similar to Patrice's virtual provides make it more obvious that this wasn't a real package? Provides: service(login) service() is a bit close to server(). Suggestions for a better name are welcome. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ life, n.: A whim of several billion cells to be you for a while.

Patrice Dumas wrote: What about: Provides: runlevel(5) ? Kevin Kofler

Bill Nottingham wrote: Provides: bikeshed(loginmanager) -- Rex

Chris Lumens (clumens(a)redhat.com) said: As a corollary, something that would allow /etc/X11/prefdm to not always be hand-edited for new options would be nice as well. Bill

Ignacio Vazquez-Abrams (ivazqueznet(a)gmail.com) said: If DISPLAYMANAGER is set, we just exec that, so we don't need changes for that. It's the fallbacks at the end that require manual editing. Bill

On 2009-02-18 at 17:14:12 -0500, Colin Walters <walters(a)verbum.org&gt; wrote: I'm not sure I buy this argument. Who gets to say what use cases are interesting to the Fedora Community? What if the next great window manager isn't GNOME or KDE? Sure, maybe other "dm"s might not make it into the default Fedora spins, but lets not start "strongly discouraging" people from writing new code and putting it in Fedora. ~spot

On Wed, Feb 18, 2009 at 5:17 PM, Tom spot Callaway <tcallawa(a)redhat.com&gt; wrote: I very strongly believe that something like Fedora can't be an abstract project to put as many different pieces of software into RPM form as possible, regardless of what kind of software it is and the ramifications for the layers involved. Instead, it should be focused on a product or goal - desktop and server images being good choices. And the question is how does the work involved impact those products. There's a huge difference between say adding some random free software OpenGL game a college student wrote on a weekend and swapping out the login system for the OS. Changing the login system has a *huge* impact on how everything works and could easily result in confusing problems higher up the stack. You can't just swap in one or the other. Besides, that argument, it's far better for the Free Software ecosystem if people try to cooperate on common projects. Bottom line is that while it's certainly within anyone's rights to add their new login manager, it's also within the rights of the people working on the desktop to close any bugs filed by people using something else WONTFIX.

On Wed, 2009-02-18 at 14:39 -0800, Jesse Keating wrote: "Supported" We don't provide support anyway. But let's be clear - if there are freedesktop.org specs on what a login manager must provide. And we have a new lm that meets those specs. We should not be telling people we won't work on bugs with that new lm. nor should we be trying to keep that lm out of fedora, i think. -sv

Am Mittwoch, den 18.02.2009, 17:53 -0500 schrieb seth vidal: Obviously... I filed three bugs against gdm, none of them got fixed, in fact they are all in state NEW or were closed by the bugzappers. IIRC none of them even got a single comment from the maintainer. That's what I call a supported login manager. ;) Regards, Christoph

On Mon, Mar 02, 2009 at 04:40:01AM -0500, William Jon McCann wrote: The question of who contributes is also an interesting question. What you want to produce also determines who is interested in contributing. Some projects are not really mainstream Fedora, yet they bring contributors who may also contribute to the core of Fedora (like XFce, lxde, OLPC...). I am confused. Ubuntu also has all of debian (not in the main repo but in the universe repo). But maybe you want to compete with the main repo only. Anyway I am not sure that competing with Ubuntu is possible given that the Ubuntu goals are different, less focused on latest upstream, with more stability. Highly integrated components in Fedora tend to break a lot and are rarely highly polished, not only loosely integrated components (in my opinion). I don't know where the idea that Fedora breaking comes from the 'bag-of-loosely-coupled-packages conception', but I disagree. It remains true that things are even more broken for loosely integrated components that need to play well with some core components, for example ConsoleKit has been broken for all the display managers except gdm and kdm. But Fedora users you are targeting won't never come in touch with anything else than gdm and kdm. Having a lot of packages doesn't prevent them from being highly integrated. For example icewm and fvwm are well integrated in Fedora, though they are not in typical Fedora setup. My personal experience is that lack of integration also come from core component packagers not looking at patches that would allow to have better integration (as in the consoleKit issue), and because the components were not designed from the ground up to be easy to integrate. -- Pat

Colin Walters wrote: Well, display managers which do not support gnome-keyring-pam simply shouldn't load the module in their PAM configuration, then all you have to do is to enter your password to unlock the keyring the first time you use it, nothing catastrophic. (By the way, we may end up doing that (no longer loading gnome-keyring-pam) for KDM because some people have issues with gnome-keyring and KDM, the strange thing is that for others it works perfectly.) Kevin Kofler

Christoph Wickert wrote: Yeah, that too. In fact not needing gnome-keyring-daemon is why I use the KDE 3 knetworkmanager and will switch to the Plasma (KDE 4) NM applet as soon as it's ready. Kevin Kofler

On Wed, Feb 18, 2009 at 9:30 PM, Toshio Kuratomi <a.badger(a)gmail.com&gt; wrote: Hm, that's stronger phrasing than what I was intending. When I say that the images and releases are products and should be a point of focus, that doesn't mean to exclusion of everything else. Obviously for example we still need developer tools, which don't come with the desktop or server products. I like this paragraph a lot (and the (snipped) next one which is an elaboration), and I agree largely. My point is really that I do not think "all software now in RPM format" is a goal. It's a *means* to various goals, such as providing developer tools, games, and yes, multiple desktop environments. But as you go farther down the stack, things get less pluggable, conflicts increase, impact on the surrounding ecosystem increases. And I think it's absolutely reasonable to expect (and receive) pushback. Building new imperfect software to replace old imperfect software doesn't sound very compelling to me... I agree we want to be accommodating. Up to a point. We have to draw a line somewhere between "Let's support Fedora/HURD"[1] and "Here's a patch to make the kernel panic if gnome-session isn't in the process list". Where that line is is a matter of debate, and it's useful to have, which in fact we are. I forgot to point out in an earlier message that there is precedent for setting up barriers for low-level software, namely the Fedora 3rd party kernel driver policy: https://fedoraproject.org/wiki/KernelDriverPolicy All I'm saying is that there should exist similar barriers for components between the kernel and the desktop. [1] And if you liked my reaction to new login managers...

On Thu, 2009-02-19 at 06:38 +0100, Kevin Kofler wrote: I think they're banned b/c a kernel module package means we're not doing the proper job of getting the module in upstream. -sv

On Thu, 2009-02-19 at 06:38 +0100, Kevin Kofler wrote: But we didn't ban non-upstream modules. Instead we made the kernel team the gateway. If the module is good enough to provide to Fedora users, it's good enough to be in the kernel package proper. This gets around the build timing / ordering issue, it prevents newer kernels from causing the module to stop building, it removes the need for gross yum/rpm hacks to handle the packages properly, it removes the need to re-create the initrd after a module update, so on and so forth. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating

On Thu, 2009-02-19 at 17:08 +0100, Kevin Kofler wrote: Wrong, by having them unworking you're preventing that class of users from testing rawhide. Bad form. Rawhide is not a dumping ground to only be worried about at release time. It also means that users who need that module have to know that module exists in order to install it, and may not even be able to install Fedora in the first place because that module isn't available on the install media. Modules like that should only be loaded if the hardware is present, and if the hardware is present and the module gets loaded and it crashes things, that module isn't good enough for Fedora users. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating

On Thu, 2009-02-19 at 14:37 -0800, Adam Williamson wrote: DKMS requires you have all the devel tools installed to get the kernel modules built. This was discarded as an option for fedora for that reason. The weirdnesses with handling kernel module updates when you're not updating the kernel (and/or both) is excruciating. If you want to do some painful reading look back at the kmod/akmod/kernmod discussion from a few years ago. -sv

Adam Williamson wrote: This is similar to how RPM Fusion's kmod (binary packages) and akmod ("source" packages similar to the DKMS ones) setup works. They must have done so, because RPM Fusion decided DKMS is not suitable for binary packages and thus developed their own solution (akmod) which uses the same specfiles for the akmod packages and the binary kmod packages. But can't we just reuse the work from RPM Fusion or from Mandriva? Kevin Kofler

Colin Walters wrote: I can agree with this. Fedora should not measure its worth by saying we have more software packaged than Foo Distro but less than Bar Distro. Everybody, package more! OTOH, Fedora contributors can measure the worthwhileness of contributing to Fedora by whether they can get the stack of packages they care about into Fedora. So my picture of this is while we don't want to encourage packaging software purely for the sake of packaging, we also don't want to discourage packaging because it conflicts with other, established subprojects. Somewhat. I think it's reasonable for people to disagree. However, I'm not sure if we agree on the definition of pushback. Let's say that someone wants to replace Xorg with Yorg, a new windowing system that makes users happy by feeding them crack. None of our existing X apps will work on Yorg. However, they can be ported with a bit of coding effort and upstream has patches for a few necessary apps like the mozilla suite, openoffice, and xterm. Do we allow Yorg in? Do we allow rebuilt versions of the apps where an upstreamed compile time flag has switched from --enable-xorg => --enable-yorg? Do we allow patched rebuilds of the apps where the patch is not upstream? I think that this is an area where we have competing interests. One of our goals in Fedora is to push the technological envelope. An actively developed new windowing system that doesn't conflict with Xorg is definitely fulfilling that goal. So keeping Yorg out seems counter to our goals. But making Yorg useful puts a burden on our present maintainers as we need to keep two versions of some apps. Yorg can't prosper without some apps to work with. At the same time, who is going to pay the cost of maintaining the new versions, triaging bugs that may be misfiled against the Xorg or Yorg versions, etc? I think those questions need to be answered. But we can't go around outlawing them. If the new maintainers show up with a triage team ready to help, coders pushing changes upstream, etc, we need to adapt. And yet, that's our exactly what we do ;-) There's always bugs, always architectural inadequacies, always something that, in retrospect, should have been designed differently. Our hope is that new imperfections are less painful than the old ones... but they're always there. So if the line is drawn between "Fedora/HURD" and "kernel panic if gnome-session isn't in the process list", which are you saying would be acceptable? ;-) These are the criteria I remember about the kernel: 1) Loadable kernel modules have the same capabilities as the kernel itself. That means, loading a kernel module can do anything the kernel does. userspace apps, even setuid apps, don't have the same power. 2) If the kernel fails, then nothing works. If firefox fails, then people use epiphany. If gnome fails, people use kde. etc. 3) Kernel modules have a strict dependence on the kernel that is built. So building out of tree kernel modules needs to have infrastructure support to kick off rebuilds immediately when the kernel is rebuilt. Having different display managers has no such requirement. 4) Kernel modules are supposed to live in the kernel tree. They get many benefits from being there. Out of tree kernel modules are possible but not something that the upstream kernel supports. The interface between the kernel and modules is unstable. Different display managers don't have this dependence on each other. 5) Bugs filed against the kernel can't be relied upon when kernel modules are present since the kernel module could affect operation of the kernel in a totally different area. This is not the same as, but similar to bugs that might occur when an application doesn't function due to using a different display manager. So only one of the considerations applies here. Looking at the reason for the kernel ban, I don't think the same justification for barriers exist in the specific case here. There could be other instances with more justification but we'd be better off discussing them when there's hard facts that we can compare and contrast against. It makes the stakes higher :-) I agree that Fedora/HURD is probably something I wouldn't support. However, I suspect my concerns are very different from yours. My reasoning is more infrastructural than policy based. Currently we don't have the knowledge-base or hardware to maintain, test, or even build HURD packages. Software would have to be coded and tested and kept running on the infrastructure side to make this a reality. Lots of work that no one's volunteered to do. -Toshio

On Wed, 2009-02-18 at 17:17 -0500, Tom "spot" Callaway wrote: I'm sure you are going to make the same argument when rpm5 comes up for inclusion again...

On Wed, Feb 18, 2009 at 6:25 PM, seth vidal <skvidal(a)fedoraproject.org&gt; wrote: My guess is that most of them would probably agree it's worth fixing bugs involved in interacting with kdm. But hostility to adding more to that set is likely to increase fast. Anyways how about this proposal as something we could likely achieve rough consensus on: Integrating any package which requires nontrivial changes in affected software[1] requires a Feature page, and that feature requires the rough consensus of the maintainers of the affected software. [1] I don't mean Requires: but how the software works at runtime

Tom "spot" Callaway wrote: While I don't think GDM and KDM are going to cut it for everyone (KDM drags in a lot of KDE, GDM a lot of GNOME, neither is a good solution for XFCE, LXDE etc.), so I do think we should support more DMs, currently the only DMs which actually *work* are those two. The serious issue with all the other DMs in Fedora is that they do not support ConsoleKit. Thus, permissions to hardware devices are not given out and things just don't work. XDM, SLIM etc. need to be patched to support ConsoleKit if we want to support them properly. As KDM is originally based on XDM, the KDM patch which I finally got upstreamed for KDE 4.2.0 should be a good starting point to fix XDM and other derivatives (though they did diverge, so some porting will be needed). I'd suggest that we make a deadline for alternative DMs: add ConsoleKit support or get dropped in F11. This has been needed since F7, they have been ignoring the problem for 4 releases now! (Whereas I fixed KDM in time for F7 on very short notice.) Don't let those DMs bitrot for a 5th release! Kevin Kofler

Colin Walters wrote: The latest GDM drags in a metric buttload of GNOME infrastructure, in particular gnome-session, which drags in control-center, which drags in pretty much all of GNOME, including metacity, libcanberra, several libgnome* etc. The days where GDM only needed GTK+ are long gone. Kevin Kofler

Am Donnerstag, den 19.02.2009, 02:05 +0100 schrieb Kevin Kofler: What is not working? Are there any DM related bugs in bz? The only one I know is related to gdm, one of the DMs you call working. What is the use if nether xfce4-session nor lxsession-lite support ConsoleKit? Regards, Christoph

On Thu, 19 Feb 2009 03:11:27 +0100 Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote: Just as a side note, yes, Xfce does support this with the thunar-volman plugin. You can tell it what to do with any number of removable devices (mount, copy pictures with gphoto2, etc). Yes, we need ConsoleKit support to work. :) kevin

Kevin Fenzi wrote: Xfce-volman IIRC is just a fork of gnome-volume-manager that we had until a release ago when Nautilus gained that functionality and g-v-m was obsoleted. So if ConsoleKit support is needed, that software is a obvious place to look for patches. Rahul

On Thu, Feb 19, 2009 at 02:05:09AM +0100, Kevin Kofler wrote: xdm has worked for me for some time (I don't remember exactly when, but at least on 2008-01-10, though the solution I came to at that point was too complicated), and I have repeatedly offered help to fix xdm. I went through different solutions, with the consolekit people completly ignoring me and my demands for clarifications and advice. It seems to me that there is a propoer fix now, in 2 bugs with patches, one for the local login and one for xdmcp (untested) the patch for xdmcp being based on yours (though xdm and kdm have diverged a lot). https://bugzilla.redhat.com/show_bug.cgi?id=452156 https://bugzilla.redhat.com/show_bug.cgi?id=237621#c13 Given that XDM has been broken for many releases, it is likely that there are no XDM users in Fedora, though. Also the XDM maintainer doesn't seem to care at all about XDM, I think that he should orphan it, such that it is really maintained. -- Pat

On Wed, Feb 18, 2009 at 02:01:30PM -0500, clumens(a)redhat.com wrote: This should not be used since there is already (or there was) a virtual provides like that added automatically. Besides I don't find it very adapted to the case at hand. I think that service() could be reserved for daemons waiting in the background. Maybe the display managers qualify for that, especially in a fast user switching world (when serving xdmcp they do, but in that case there is already the server(xdmcp) virtual provides). Using service(graphical-login) has the advantage to be more general, the disadvantage to be less precise. -- Pat