Re: Requiring systemd for the gnome-settings-daemon power plugin
On Mon, 2012-10-22 at 22:56 +0200, Frederic Peters wrote: Bastien Nocera wrote: Additionally, and separately, support for ConsoleKit usage for session-tracking will be removed. This is now pushed to master for 3.7.1. Well, this all happened a few days before the release deadline, this is not easy matter, we have a release team meeting this week-end and we will talk about the whole situation. Of course this is still just 3.7.1, but anyway. I'd suggest we do *not* ship gnome-settings-daemon 3.7.1 in GNOME 3.7.1 and wait for a project-wide decisionon how support of ConsoleKit systems should be (dis)continued. What was the outcome of the meeting then? (From the correct address this time) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Wed, Oct 31, 2012 at 7:44 AM, Bastien Nocera had...@hadess.net wrote: What was the outcome of the meeting then? We didn't have quorum for very long, so the discussion was cut short. We'll continue next weekend. The preliminary outcome so far has been summed up in the meeting notes like this: = Systemd/CK = - No hard compile time dep on systemd for basic functionality example of basic functionality: active session tracking example of non-basic functionality: power management - Collaborate more between modules - Need active people maintaining CK bits ideally in tree ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Tue, 2012-10-23 at 08:53 -0400, Colin Walters wrote: On Tue, 2012-10-23 at 07:26 +0200, Bastien Nocera wrote: I don't see how this helps. The code just lives somewhere that's still within view (gnome-desktop isn't some magic module where things get hidden), But I'm also volunteering to help keep it compiling and at least the systemd case tested. You're *really* rejecting this based on the premise that the CK code would exist somewhere in GNOME and it's too much of a burden on you to ever even look at it? At least Florian's reply earlier in the thread implied that he thought centralizing the logind/CK burden would be a good idea, and I'd take that to mean he would spend a bit of time helping out. I just ran git log gnome-settings-daemon/gnome-settings-session.c in the gnome-3-6 branch. You have *never modified this code*. It's Richard, Rodrigo, Federico, and Matthias. So I'm dubious about a claim that this code is so dire that you can't even be bothered to have a dependency containing it. I didn't say the bug was dire. I said that it would need to be maintained. As for the I've never touched this code, I'm fairly certain that I reviewed every change to it, which you can verify by opening up the bugs referenced. If this is the sort of thing you want to mention, we might want to mention that I've committed more code to gnome-desktop than you have. Did you really want to make this into a pissing contest? I'm not Guybrush. And let's be clear, there's no maintainer for gnome-desktop. gnome-settings-daemon's power plugin still requires logind to work, Now in contrast to the session is active code, this is a complex codebase; 5000 lines is nothing to sneeze at. Also, this bit is special to g-s-d, unlike the session is active bit which a number of other modules (gnome-shell e.g.) also need to query. So it seems to me well within your rights as maintainer to say only systemd is supported here. and gnome-shell with upower/ConsoleKit will likely behave brokenly (given that there's no gnome-settings-daemon counter-part). But the point is that we're not *regressing* anything for the CK case. Sure, GNOME in the CK case will have bugs. That's fine by me. GNOME has plenty of bugs, some of them even very embarrassing. What's the sudden attachment to ConsoleKit? You could just as easily 1) port to g-s-d logind code to use D-Bus, and write a shim on top of ConsoleKit that would export a similar API. I took the previously working code. It's not clear to me what benefit the changes you're talking about would provide other than turning compile-time detection into runtime detection, which is kind of useful but not of critical importance. Two important benefits: - the onus of updating/fixing/releasing the CK portion of code isn't mine, or any of the other gnome-settings-daemon/gnome-control-center developers. It's really a toss up between gnome-shell, gnome-settings-daemon and gnome-session as to who would get the bugs when CK behaves badly (or brings in other - I can use any API I want in the code using logind without having to think about ConsoleKit, or thinking about having this exact same conversation in 6 months. So what's the path forward in your eyes? Are you still suggesting that GNOME immediately delete all CK code? To be clear, my proposed plan is: * Spend a little bit (not necessarily a lot) of effort to avoid regressing CK. * It's OK if new features or bugfixes rely on logind. * If particular complex functionality like the g-s-d power plugin gets too hard to map to both CK/logind, announce that in advance, give a warning that code will be deleted, if no one steps up to help, delete it. If we keep on supporting CK, we'll be the ones getting the bug reports about such and such part of the system being broken or badly behaving because that configuration, we support it, kind of, but not really. You wanted something coherent, you'll end up with a box of ill-fitting bits. You still haven't answered why it's important to keep ConsoleKit. We're giving 6 months headway to people that'll need to replace it, which, from your code, should fairly trivial. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Wed, Oct 24, 2012 at 4:11 AM, Bastien Nocera had...@hadess.net wrote: You still haven't answered why it's important to keep ConsoleKit. We're giving 6 months headway to people that'll need to replace it, which, from your code, should fairly trivial. I've spent 30 minutes looking into this, this morning. I've attached the logind D-Bus apis that I found being used in gnome-session, gnome-shell and gnome-settings-daemon. That looks easy enough, but there's some complications: - The shell assumes that the object path for the current session object is /org/freedesktop/login1/session/ + getenv (XDG_SESSION_ID), I'm sure there's other assumptions like this elsewhere - We expect PrepareForSleep to be emitted before and after suspend/resume, which is hard to do, as we learned in upower - The inhibit api is using a mix of D-Bus with fd passing and an fd-based api - The session state api used in GnomeSettingsSession is not using D-Bus, but a library api which is based upon various filesystem interfaces (/sys/fs/cgroup/systemd, /run/systemd/, plus an fd-based api for notification. The actual api we're using is minimal: sd_login_monitor_new sd_login_monitor_get_fd sd_login_monitor_flush sd_session_is_active Is it possible to reimplement this all compatibly inside ConsoleKit ? Probably. But 'fairly trivial', I'm not so sure about. ?xml version=1.0 encoding=UTF-8? node name=/org/freedesktop/login1/Manager xmlns:doc=http://www.freedesktop.org/dbus/1.0/doc.dtd; interface name=org.freedesktop.login1.Manager method name=GetSession arg name=session_id type=s direction=in/ arg name=object_path type=o direction=out/ /method method name=Reboot arg name=allow_interaction type=b direction=in/ /method method name=PowerOff arg name=allow_interaction type=b direction=in/ /method method name=Suspend arg name=allow_interaction type=b direction=in/ /method method name=Hibernate arg name=allow_interaction type=b direction=in/ /method method name=CanReboot arg name=result type=s direction=out/ /method method name=CanPowerOff arg name=result type=s direction=out/ /method method name=CanSuspend arg name=result type=s direction=out/ /method method name=CanHibernate arg name=result type=s direction=out/ /method method name=Inhibit arg name=what type=s direction=in/ arg name=who type=s direction=in/ arg name=why type=s direction=in/ arg name=type type=s direction=in/ arg name=fd_index type=i direction=out/ /method method name=SetIdleHint arg name=is_idle type=b direction=in/ /method signal name=PrepareForSleep arg name=about_to_suspend type=b direction=out/ /signal /interface interface name=org.freedesktop.login1.Session signal name=Lock/ signal name=Unlock/ /interface /node ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Wed, 2012-10-24 at 06:25 -0400, Matthias Clasen wrote: On Wed, Oct 24, 2012 at 4:11 AM, Bastien Nocera had...@hadess.net wrote: You still haven't answered why it's important to keep ConsoleKit. We're giving 6 months headway to people that'll need to replace it, which, from your code, should fairly trivial. I've spent 30 minutes looking into this, this morning. I've attached the logind D-Bus apis that I found being used in gnome-session, gnome-shell and gnome-settings-daemon. That looks easy enough, but there's some complications: - The shell assumes that the object path for the current session object is /org/freedesktop/login1/session/ + getenv (XDG_SESSION_ID), I'm sure there's other assumptions like this elsewhere - We expect PrepareForSleep to be emitted before and after suspend/resume, which is hard to do, as we learned in upower - The inhibit api is using a mix of D-Bus with fd passing and an fd-based api - The session state api used in GnomeSettingsSession is not using D-Bus, but a library api which is based upon various filesystem interfaces (/sys/fs/cgroup/systemd, /run/systemd/, plus an fd-based api for notification. The actual api we're using is minimal: sd_login_monitor_new sd_login_monitor_get_fd sd_login_monitor_flush sd_session_is_active Is it possible to reimplement this all compatibly inside ConsoleKit ? Probably. But 'fairly trivial', I'm not so sure about. The object Colin proposed adding only covers the last section, which has D-Bus equivalent. That's fairly trivial. I wasn't commenting on any of the other uses of logind, seeing as that's not what we're discussing. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Wed, Oct 24, 2012 at 6:31 AM, Bastien Nocera had...@hadess.net wrote: I wasn't commenting on any of the other uses of logind, seeing as that's not what we're discussing. The thing is that you can't just reimplement one piece 'compatibly inside ConsoleKit' - once org.freedesktop.login1 is on the bus, other parts of the desktop will assume they can use logind functionality. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Wed, 2012-10-24 at 06:38 -0400, Matthias Clasen wrote: On Wed, Oct 24, 2012 at 6:31 AM, Bastien Nocera had...@hadess.net wrote: I wasn't commenting on any of the other uses of logind, seeing as that's not what we're discussing. The thing is that you can't just reimplement one piece 'compatibly inside ConsoleKit' - once org.freedesktop.login1 is on the bus, other parts of the desktop will assume they can use logind functionality. They will fail gracefully when a function call fails, won't they? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Wed, 2012-10-24 at 10:11 +0200, Bastien Nocera wrote: And let's be clear, there's no maintainer for gnome-desktop. I do look at incoming bugs and review patches, though since the module is a bit of a grab bag, for things like randr I'll toss reviews of those bits to Federico if he wasn't the original author. - the onus of updating/fixing/releasing the CK portion of code isn't mine, or any of the other gnome-settings-daemon/gnome-control-center developers. It's really a toss up between gnome-shell, gnome-settings-daemon and gnome-session as to who would get the bugs when CK behaves badly (or brings in other No disagreement, this is an ongoing burden. - I can use any API I want in the code using logind without having to think about ConsoleKit, or thinking about having this exact same conversation in 6 months. And for the project in general, dropping out a whole column from the test matrix (gnome-shell with CK, fallback mode with systemd) is indeed a notable win. If we keep on supporting CK, we'll be the ones getting the bug reports about such and such part of the system being broken or badly behaving because that configuration, we support it, kind of, but not really. You wanted something coherent, you'll end up with a box of ill-fitting bits. True. You still haven't answered why it's important to keep ConsoleKit. Because I'm opposing your methods here on *general principle*. I don't care about ConsoleKit (the codebase) much at all. What I do care about is when I go to GUADEC and hang out with some of the Debian or Ubuntu people who rely on CK, we have a sense that we're part of a shared project. I'm all for making GNOME+systemd kick ass. But not at the cost of giving up the rough consensus and working code aspect that forms GNOME and other FOSS projects. Your process here was to post on a Friday that you were going to delete the code, have a lot of feedback even over the weekend, then on Monday *do it anyways*. That's just not the way we should approach problems in GNOME. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Wed, Oct 24, 2012 at 8:47 AM, Colin Walters walt...@verbum.org wrote: On Wed, 2012-10-24 at 10:11 +0200, Bastien Nocera wrote: ... You still haven't answered why it's important to keep ConsoleKit. Because I'm opposing your methods here on *general principle*. I don't care about ConsoleKit (the codebase) much at all. What I do care about is when I go to GUADEC and hang out with some of the Debian or Ubuntu people who rely on CK, we have a sense that we're part of a shared project. I'm all for making GNOME+systemd kick ass. But not at the cost of giving up the rough consensus and working code aspect that forms GNOME and other FOSS projects. What this should mean, to me, is that we are all working toward the same goals. What are those goals? They are perhaps best found by considering what does the user see? http://blog.fishsoup.net/2011/03/11/what-does-the-user-see/ The code serves that purpose and that purpose alone. I wrote ConsoleKit. I wrote it for GNOME. I wrote it because we needed it to get fast user switching working in gnome-screensaver, we needed it for sane device support I was working on for Rhythmbox, I worked with David to make sure it fit the needs of HAL, which was needed to get the device support right for Nautilus. In my first analysis of the problem I concluded it was something the OS should have been doing all along and really ought to have been part of the kernel or very low level userspace. I had started to investigate creating a new init system that would have a more modern process group / session leader concept included. At about the same time, Upstart started. The project seemed promising and I changed my strategy. ConsoleKit was a stop-gap measure. Just enough working code to do the job we needed, and only the job we needed, at the time. But now we have different needs. And something entirely better has come along. So, I no longer maintain or support the use of ConsoleKit. I handed ConsoleKit off to Lennart. To do as he saw fit. I agree with you that it is wrong to arbitrarily remove code from our core system. That kind of churn is disruptive. It must be motivated by a need. It should be motivated by what the user will see. And what experiences we want to provide. It is. We have designs on the table that motivate the use of systemd. There are a number of them (some more subtle) but I'll just mention just two: https://live.gnome.org/Design/Apps/SystemLog https://live.gnome.org/GnomeOS/Design/Whiteboards/ProblemReporting The first one mostly uses the journal directly but the second uses the journal and probably systemd core to handle some of the response to application misbehavior. In addition, we also have had long standing plans to improve the way we start and manage the session services. I was one of the main contributors to the current gnome-session. I was clear during that rewrite that it too was a stop-gap solution. The difficulties there were quite similar to the start and management of system services. I investigated logind at the time and decided we should just do something that solved the immediate need and wait for a more complete solution. We have one. Systemd can already do this I'm told. It is motivated by the user experience. Faster start up, more robust failure detection, better diagnostic information during failures, consistent tools, etc. I agree with you that we need to have a motive to change and that costs should be weighed carefully. We can make the case. What is unwise, in my opinion, is ifdef'ing or branching the user experience to suit the code. I don't think it is useful to even discuss whether we should remove ConsoleKit or not. We must. It is on life support. If we are still able to move forward with the user experience changes we need to make while maintaining some compatibility - fine. But we need to have an end game. This is a lesson we have learned over and over. Let's not make the same mistakes again. I think it would be in the interest of all parties to have the conversation about why some are unwilling to use the best components available today to allow us to go forward and make the user experience as good as it can be. That is the best kind of rough consensus and working code. The one that matters for what the user sees. Thanks, Jon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Wed, 2012-10-24 at 08:47 -0400, Colin Walters wrote: I'm all for making GNOME+systemd kick ass. But not at the cost of giving up the rough consensus and working code aspect that forms GNOME and other FOSS projects. Your process here was to post on a Friday that you were going to delete the code, have a lot of feedback even over the weekend, then on Monday *do it anyways*. I carefully answered every comment, and didn't make the decision lightly either. I could see 2 people with concerns over it, one concerned with OpenBSD, one with Ubuntu and Unity. Did I miss some opinions while making this decision? And even if I did not address all those concerns, am I contravening to the rules that were set out a year ago? https://live.gnome.org/ReleasePlanning/WhatWeRelease That's just not the way we should approach problems in GNOME. GNOME's way seems to be to postpone the hard decisions 6-month down the line. I've already had those same problems when I wanted to remove the date and time helper in January, even though we discussed having systemd as an external dependency in May the year before. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
William Jon McCann wrote: I agree with you that we need to have a motive to change and that costs should be weighed carefully. We can make the case. The objection Colin expressed was about the method; and on that matter, frankly, we are making a good job in alienating active members of our community, to the point our GNOME is people is no more but a slogan.[1] We have active members using Debian, Ubuntu, Gentoo, OpenBSD, whatever, for whatever *good* reasons, and more often than not they will have nothing to do with GNOME. You may not want to compromise with code, I want to compromise with people, this definitely takes longer, this takes emails, this takes discussions, this is in my opinion important. And this certainly doesn't mean we are not going forward. Fred [1] let's wait for somebody to register gnomeispeople.org and put a big no, it's not on it... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Wed, 2012-10-24 at 16:42 +0200, Frederic Peters wrote: William Jon McCann wrote: I agree with you that we need to have a motive to change and that costs should be weighed carefully. We can make the case. The objection Colin expressed was about the method; and on that matter, frankly, we are making a good job in alienating active members of our community, to the point our GNOME is people is no more but a slogan.[1] We have active members using Debian, Ubuntu, Gentoo, OpenBSD, whatever, for whatever *good* reasons, and more often than not they will have nothing to do with GNOME. You may not want to compromise with code, I want to compromise with people, this definitely takes longer, this takes emails, this takes discussions, this is in my opinion important. And this certainly doesn't mean we are not going forward. Talking more doesn't automatically mean that you're taking the right decision. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Wed, 2012-10-24 at 09:36 -0400, William Jon McCann wrote: I agree with you that we need to have a motive to change and that costs should be weighed carefully. We can make the case. Yes. You've done some of that here. As we discussed on IRC, stuff like having GNOME tightly integrated with the journal would be very compelling. What is unwise, in my opinion, is ifdef'ing or branching the user experience to suit the code. There is as you say below, a short term and a long term. Short term, dealing with some ifdefs seems quite doable to me. But for the medium term, we should gather a list of features that depend on systemd. For each of those features, some of them can just not exist if GNOME isn't compiled with systemd. Structured logging probably falls into this category. Others, like systemd-as-gnome-session, would clearly be a huge amount of nontrivial duplication if we tried to support both. It's a no-going-back type situation. Really we're talking about 3 possible paths, in increasing order of dependence/benefit: 1) No hard dep on systemd, maintain current CK bits to a greater or lesser degree. 2) No hard dep on systemd, but delete CK bits. 3) Hard dep on systemd. You are talking about 3). Bastien was trying to accomplish 2) (but the current g-s-d code actually has a hard dep), and what I was going for in the *short* term is to maintain the status quo of 1). I'm not sure how much it makes sense though to spend a cycle or two doing 2) if what we're *really* going for is 3). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Wed, Oct 24, 2012 at 11:28:45AM -0400, Colin Walters wrote: On Wed, 2012-10-24 at 09:36 -0400, William Jon McCann wrote: I agree with you that we need to have a motive to change and that costs should be weighed carefully. We can make the case. Yes. You've done some of that here. As we discussed on IRC, stuff like having GNOME tightly integrated with the journal would be very compelling. What is unwise, in my opinion, is ifdef'ing or branching the user experience to suit the code. There is as you say below, a short term and a long term. Short term, dealing with some ifdefs seems quite doable to me. But for the medium term, we should gather a list of features that depend on systemd. For each of those features, some of them can just not exist if GNOME isn't compiled with systemd. Structured logging probably falls into this category. Others, like systemd-as-gnome-session, would clearly be a huge amount of nontrivial duplication if we tried to support both. It's a no-going-back type situation. Really we're talking about 3 possible paths, in increasing order of dependence/benefit: 1) No hard dep on systemd, maintain current CK bits to a greater or lesser degree. 2) No hard dep on systemd, but delete CK bits. 3) Hard dep on systemd. You are talking about 3). Bastien was trying to accomplish 2) (but the current g-s-d code actually has a hard dep), and what I was going for in the *short* term is to maintain the status quo of 1). I'm not sure how much it makes sense though to spend a cycle or two doing 2) if what we're *really* going for is 3). I fully agree with this last statement and it's the main reason I raised some concerns in my initial mail. -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
2012/10/24 Bastien Nocera had...@hadess.net Talking more doesn't automatically mean that you're taking the right decision. Only a Sith deals in absolutes! -- Obi Wan Kenobi Seriously though, the right decision might mean different things to different people, there is no absolute ¨right decision¨, there may be overlooked implications to these decisions, and there may be unwanted consequences. And what would be great for some it could be a nightmare for others. Let's not forget that we are part of an ecosystem, and even though I see value on taking bold steps to help shape the stack (systemd widespread adoption is something I personally support) the way in what we do it is certainly important. I don't think we should pursue the goal of making *everybody* happy but I am certainly not comfortable to this way of dealing with this sort of changes, the problem as I see it is that you have made the decision on your own (or rather, it's easy to think so), even though it affects a lot of people (distro developers and those distro's users) and no matter what input you've gotten you have not acknowledge that those points of view as valid concerns. You are giving no constructive alternatives to the very people consuming the software you are maintaining. Which is specially annoying when you justify the decision on maintainership burden and people is stepping up to help (I have yet not seen you stating that if someone helps, you'll be open to reconsider or help with alternatives). Sometimes it's hard to point out these conflicts with maintainers, not everybody steps up to help and at the same time some of us don't want to alienate people doing the job. But we create GNOME in an ecosystem and seeking consensus is key if we want to nurture a vibrant community. As Colin has pointed out, this is not saying that you are wrong with moving fully to systemd rather than discussing how and when do we get there. Just my two cents. -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
El mié, 24-10-2012 a las 16:39 +0200, Bastien Nocera escribió: GNOME's way seems to be to postpone the hard decisions 6-month down the line. I've already had those same problems when I wanted to remove the date and time helper in January, even though we discussed having systemd as an external dependency in May the year before. Perhaps this discussions could come with a window of at least a week or so of comments. Even if it is just catharsis, informally waiting a week could be a great tension reliever. Consider that so far the consensus is that systemd is the right thing to do, the devil is in the details of how, and how fast, we are going there without distressing fewllow contributors. Diego ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Matthias Clasen [2012-10-24 6:38 -0400]: The thing is that you can't just reimplement one piece 'compatibly inside ConsoleKit' - once org.freedesktop.login1 is on the bus, other parts of the desktop will assume they can use logind functionality. And worse, you couldn't run systemd and CK side by side any more, as CK would trample over systemd's namespace. But for migrating to systemd this is necessary for a while, until all packages in a distro have been ported. I think that Ubuntu, BSD, etc. should not try to put a half-arsed reimplementation of logind into CK, that's only going to cause confusion as you said; I think it is much cleaner to patch gnome-session and g-s-d to use CK instead of logind; after all, that code exists and works, you just need to maintain the patches for newer upstream versions. That's a fair price to pay IMHO. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Tue, 2012-10-23 at 07:26 +0200, Bastien Nocera wrote: I don't see how this helps. The code just lives somewhere that's still within view (gnome-desktop isn't some magic module where things get hidden), But I'm also volunteering to help keep it compiling and at least the systemd case tested. You're *really* rejecting this based on the premise that the CK code would exist somewhere in GNOME and it's too much of a burden on you to ever even look at it? At least Florian's reply earlier in the thread implied that he thought centralizing the logind/CK burden would be a good idea, and I'd take that to mean he would spend a bit of time helping out. I just ran git log gnome-settings-daemon/gnome-settings-session.c in the gnome-3-6 branch. You have *never modified this code*. It's Richard, Rodrigo, Federico, and Matthias. So I'm dubious about a claim that this code is so dire that you can't even be bothered to have a dependency containing it. gnome-settings-daemon's power plugin still requires logind to work, Now in contrast to the session is active code, this is a complex codebase; 5000 lines is nothing to sneeze at. Also, this bit is special to g-s-d, unlike the session is active bit which a number of other modules (gnome-shell e.g.) also need to query. So it seems to me well within your rights as maintainer to say only systemd is supported here. and gnome-shell with upower/ConsoleKit will likely behave brokenly (given that there's no gnome-settings-daemon counter-part). But the point is that we're not *regressing* anything for the CK case. Sure, GNOME in the CK case will have bugs. That's fine by me. GNOME has plenty of bugs, some of them even very embarrassing. What's the sudden attachment to ConsoleKit? You could just as easily 1) port to g-s-d logind code to use D-Bus, and write a shim on top of ConsoleKit that would export a similar API. I took the previously working code. It's not clear to me what benefit the changes you're talking about would provide other than turning compile-time detection into runtime detection, which is kind of useful but not of critical importance. So what's the path forward in your eyes? Are you still suggesting that GNOME immediately delete all CK code? To be clear, my proposed plan is: * Spend a little bit (not necessarily a lot) of effort to avoid regressing CK. * It's OK if new features or bugfixes rely on logind. * If particular complex functionality like the g-s-d power plugin gets too hard to map to both CK/logind, announce that in advance, give a warning that code will be deleted, if no one steps up to help, delete it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 12:07 -0400, Colin Walters wrote: On Fri, 2012-10-19 at 15:48 +0200, Bastien Nocera wrote: I would recommend that gnome-shell uses systemd to suspend, and I would recommend gnome-shell, gnome-session and gdm also drop their ConsoleKit session tracking code. At the end of the day, the decisions are not mine to make, so if the costs of keeping those options are low enough for you, then feel free to keep them. But in reality, the set of git repositories forms a whole. And if gnome-settings-daemon doesn't support !systemd, then the whole doesn't either. So if you decide to delete this code from g-s-d, it makes the work of anyone else completely pointless. Broadly speaking, I don't think it makes sense for this to be up to individual module maintainers as they please, because the result is incoherent. The result would be incoherent. Except that I cannot take decisions for other module maintainers, for fear of being seeing as overbearing and (paraphrasing) thrusting changes upon GNOME which would then get whitewashed as maintainers discretion. Now, this is obviously not a new debate. One option which I'd like to preserve at least is that !systemd platforms are able to build and run GNOME in basic window management mode. Basically the equivalent of thin client/remote X display. It won't crash if logind isn't available, we'd just disable the power plugin. So we could say we don't support power management for example. In that case, you could support being compiled without systemd support (at present), and just do nothing if it doesn't exist. Or it could be runtime detection. Given that there are no library dependencies, it would always be run-time detection, as it was and as it will be. No change there. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 13:33 -0500, Brian Cameron wrote: The GNOME community provides little guidance about what systemd interfaces are actually needed for various GNOME features to work properly. Maybe nobody really knows yet, but non-Linux distros will likely make slow progress as long as there is so little good guidance. This page: https://live.gnome.org/PortabilityMatrix was created for that purpose 6 months ago. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 19:20 +0200, Sebastien Bacher wrote: Le 19/10/2012 15:41, Matthias Clasen a écrit : I don't think that is a very productive way to have a discussion. What are you hoping to achieve ? The discussion went this way: 1: g-s-d will drop non systemd support 2: could we define standard interface that are up to the distributor to implement rather than depends on systemd? an hard depends would mean those choices for non systemd distributors: list of options I could see 1: no, I don't intend to spend any time on that, if you don't want to use systemd you need to work with systemd upstream 2: ok, well I guess we need to think what to do then, but it's limiting our options to get GNOME shipped could we define standard interface I don't intend to spend any time on that Notice the pronouns. You're more than welcome helping define the interfaces, there's just not going to be me there, helping out. I'm not sure how unproductive it has been, it's merely stating intends and sharing concerns... What I'm hoping to achieve? I guess letting know GNOME, as a project, know in what position this choice put some of the distributors and what might be the outcome. It's sharing information and communicating ... is there any issue with that? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 17:48 +0200, Antoine Jacoutot wrote: Sure, but my initial concern is that once you have one foot in systemd, why not embrace it totally? What does embracing totally mean? If there are more features in systemd to simplify or better GNOME, we'll certainly use them. But there isn't a grand master plan with a list of systemd features that don't exist yet that we'll use next in GNOME. Hindsight would be a wonderful thing to have. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 11:14 +0200, Antoine Jacoutot wrote: On Fri, Oct 19, 2012 at 11:00:05AM +0200, Bastien Nocera wrote: Hello, I intend on making systemd a hard requirement for the power plugin in gnome-settings-daemon. There is a lot of interactions and external factors involved in making policy decision about power. This makes the power plugin one of the more fragile parts of the system, with things like DPMS, screensaver activation, screen locking, brightness control, suspend policy, battery information exporting, all handled in the same codebase. Using systemd to request suspends means that: - things work out of the box when people do not use GNOME (no need to install acpid which then conflicts with GNOME) - inhibitions are per-system instead of per-user - application get more information about suspending - simplify the power plugin's codebase a great deal The patches I will commit are here: https://bugzilla.gnome.org/show_bug.cgi?id=680689 Additionally, and separately, support for ConsoleKit usage for session-tracking will be removed. I think at one point the GNOME project will need to step up and explicitely states that GNOME is a Linux-only Desktop. I am a BSD user; don't get me wrong, if GNOME goes Linux-only then so be it. But the current situation is hard for us because it is unclear where all of this is going. When systemd was first mentionned on the lists, it was said it wouldn't be a hard requirement. systemd wasn't a requirement to implement the features we needed. We need other features, and the maintenance requirements are different. Fair enough, we are only talking about the power plugin here but the way it is going systemd will soon be needed for more important features. I'm just wondering if it is still worth trying to maintain GNOME for ! linux platforms (like I do on OpenBSD). Implementing some of what systemd provides is far from trivial for us. To summarize, it'd be nice to know whether there is still a chance to see GNOME running on BSD in a near future. If everything is going systemd, then the answer is clear, but for now I lack the information. Whether GNOME still works on OpenBSD is up to you, and the amount of time and effort you're willing to spend keeping up with the reference implementation. We cannot tell you when the work needed to keep up will be too big, we also cannot tell you when the features systemd implements will be too hard to replicate on OpenBSD. To answer your question, if those are the only systemd changes happening for 3.8, then GNOME 3.8 will run on OpenBSD as well as it used to, but without multi-seat handling or power management. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 17:48 +0200, Antoine Jacoutot wrote: On Fri, Oct 19, 2012 at 07:43:26AM -0400, Matthias Clasen wrote: On Fri, Oct 19, 2012 at 5:14 AM, Antoine Jacoutot ajacou...@gnome.org wrote: I think at one point the GNOME project will need to step up and explicitely states that GNOME is a Linux-only Desktop. I am a BSD user; don't get me wrong, if GNOME goes Linux-only then so be it. But the current situation is hard for us because it is unclear where all of this is going. When systemd was first mentionned on the lists, it was said it wouldn't be a hard requirement. Fair enough, we are only talking about the power plugin here but the way it is going systemd will soon be needed for more important features. I'm just wondering if it is still worth trying to maintain GNOME for !linux platforms (like I do on OpenBSD). Implementing some of what systemd provides is far from trivial for us. To summarize, it'd be nice to know whether there is still a chance to see GNOME running on BSD in a near future. If everything is going systemd, then the answer is clear, but for now I lack the informationit Hey Antoine, I think there's a good chance for GNOME running on BSD, thanks to people like you who keep things working. I can imagine it feels like a sysiphus job at times - I hope you get thank-you letters from BSD/GNOME users every now and then... Actually I do, yes :) Bastien is speaking as the gnome-settings-daemon maintainer, and I can understand why he wants to get rid of the complicated maze of talk-to-upower-or-to-consolekit-or-to-systemd. It is his decision to make in the end, but there is certainly enough time between now and 3.8 to evaluate the best way to keep things working on BSD, no need to throw in the towel now. Sure, but my initial concern is that once you have one foot in systemd, why not embrace it totally? If we are talking about implementing a couple of systemd interfaces, fine. If the end goal is to need most of systemd to have a working Desktop environment then I am very much concerned and would love to know about it. Note that my concern is very selfish I agree, I am using GNOME not just as a personnal Desktop but also maintain several thousands installations. That's why I am even more interested about the direction it is going. The way I see it is that people were depending on somewhat proven portable technologies (for the most part) and the arrival of systemd now splits the community. I don't see systemd as just another dependency, it's deeper than that because it aggregates lots of things that could originally be into separate projects. Don't see this as a rant against systemd, it's not; I'm just confused a Desktop environment has to depend on such specific low-level software. Because we want the desktop to not feel tacked on. Having had to correct kernel bugs, udev bugs, X.org bugs, etc. to get some GNOME features working, or fix user bugs, I don't consider root daemons to be low-level. I also don't think suspend or multi-seat/fast-user switching support is something that you want to tack on. You need integration in the desktop to do it well. If I want to explain it in a very stupid way: why does an init/cron/syslog/... replacement is needed to change a timezone or track user sessions? It's not an init replacement, as is pretty clear from the functionality it provides. Not my battle though. It's not, probably. But the problem is that systemd implements lots of these things, it's not the fault of the GNOME project of course, but if some of the interfaces were actually separated from systemd, it would make it way easier for distributions or BSD systems that don't use systemd to implement them and submit portability patches (which are not accepted in systemd itself anyway). Then they would have the same problem that GNOME has now, namely that they would be held back by portability rather than pushing the functionality forward. Since this is not the case, I am a bit disappointed that GNOME relies on such interfaces... We rely on the D-Bus interface. You can reimplement that interface on your system. Hopefully my mail will not be seen as a dumb rant, I just wanted to express and explain some of the frustration I have experienced ;-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 11:00 +0200, Bastien Nocera wrote: Hello, I intend on making systemd a hard requirement for the power plugin in gnome-settings-daemon. There is a lot of interactions and external factors involved in making policy decision about power. This makes the power plugin one of the more fragile parts of the system, with things like DPMS, screensaver activation, screen locking, brightness control, suspend policy, battery information exporting, all handled in the same codebase. Using systemd to request suspends means that: - things work out of the box when people do not use GNOME (no need to install acpid which then conflicts with GNOME) - inhibitions are per-system instead of per-user - application get more information about suspending - simplify the power plugin's codebase a great deal The patches I will commit are here: https://bugzilla.gnome.org/show_bug.cgi?id=680689 Additionally, and separately, support for ConsoleKit usage for session-tracking will be removed. This is now pushed to master for 3.7.1. https://live.gnome.org/PortabilityMatrix has been updated to reflect those changes. See gnome-shell bugs: https://bugzilla.gnome.org/show_bug.cgi?id=686626 https://bugzilla.gnome.org/show_bug.cgi?id=686482 gnome-session: https://bugzilla.gnome.org/show_bug.cgi?id=686629 Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Mon, 2012-10-22 at 08:07 +0200, Bastien Nocera wrote: Given that there are no library dependencies, it would always be run-time detection, as it was and as it will be. No change there. In the current code, libsystemd-login is a hard compile-time dependency, introduced by http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=a1ab95fae75dd61fd50165b4d8a08b5588245273 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Mon, 2012-10-22 at 07:57 -0400, Colin Walters wrote: On Mon, 2012-10-22 at 08:07 +0200, Bastien Nocera wrote: Given that there are no library dependencies, it would always be run-time detection, as it was and as it will be. No change there. In the current code, libsystemd-login is a hard compile-time dependency, introduced by http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=a1ab95fae75dd61fd50165b4d8a08b5588245273 My mistake, that's because the old (ifdef'ed) code used it. The D-Bus interface[1] provides the same functionality[2]. I'll take patches to make it use the D-Bus interface. Cheers [1]: http://www.freedesktop.org/wiki/Software/systemd/logind [2]: http://www.freedesktop.org/software/systemd/man/sd_login_monitor_new.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Mon, 2012-10-22 at 14:04 +0200, Bastien Nocera wrote: My mistake, that's because the old (ifdef'ed) code used it. The D-Bus interface[1] provides the same functionality[2]. I'll take patches to make it use the D-Bus interface. Right, ok rather than that, I can take over maintaining this bit of code for now. Here's patches to move it to gnome-desktop, and update gnome-settings-daemon to depend on it: gnome-desktop: https://bugzilla.gnome.org/show_bug.cgi?id=686649 gnome-settings-daemon: https://bugzilla.gnome.org/show_bug.cgi?id=686650 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Bastien: I was not trying to suggest that there was no GNOME portability documentation. Instead I was saying that it should not be surprising that non-Linux distros (and many popular Linux distros) are making very slow progress with GNOME 3 based on the quality and scope of the existing documentation. https://live.gnome.org/PortabilityMatrix The Portability Matrix you highlight is a good example of this. The matrix highlights that some distros use different solutions for various features, but no information is provided to help any distro know what should be considered when making decisions. Most of the rows in the matrix assume that the reader already understands what is even being described. For example, the matrix highlights that gsd power features use logind. Most readers would likely need to review the code to understand what specific power features are actually being described here or why they might need logind. Most rows in the table are like this, so this matrix is only a very useful guide if the reader has many hours to invest to understand how the information applies to them. To me, the matrix looks more like a draft of an outline to a guide, but it is a start. On 10/22/12 01:15 AM, Bastien Nocera wrote: On Fri, 2012-10-19 at 13:33 -0500, Brian Cameron wrote: The GNOME community provides little guidance about what systemd interfaces are actually needed for various GNOME features to work properly. Maybe nobody really knows yet, but non-Linux distros will likely make slow progress as long as there is so little good guidance. This page: https://live.gnome.org/PortabilityMatrix was created for that purpose 6 months ago. Considering GNOME 3.6 is out the door, 6 months ago seems already quite late to be providing guides on how to port to GNOME 3, but late is better than never. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Hey, On Mon, Oct 22, 2012 at 11:18 AM, Brian Cameron brian.came...@oracle.com wrote: Most readers would likely need to review the code to understand what specific power features are actually being described here or why they might need logind. Most rows in the table are like this, so this matrix is only a very useful guide if the reader has many hours to invest to understand how the information applies to them. To me, the matrix looks more like a draft of an outline to a guide, but it is a start. You are talking about shipping a *complete* and *free* (libre *and* gratis) graphical desktop environment and you're complaining that you have to spend a couple of hours *reviewing* the code and/or turning off the features that you *did not* participate in developing because you choose to use a different OS than the people who actually *did* spend time working on the feature? I don't think that's fair at all - and I really have to constrain myself to not use stronger language here. Instead, may I suggest getting involved early and voicing your concern *during development* so we can either add an abstractions (such as e.g. GVolumeMonitor, GDrive, GVolume, GMount) or ifdefs or whatever [1] and avoid situations like this? Surely, the way it needs to work in GNOME is that if distributors show up and do portability-work (and it's good enough) [2] it will get merged. But it involves actually showing up and doing the work and not just sending e-mail. But please don't expect others to port GNOME to run on your OS. David [1] : Abstractions can happen at several levels: D-Bus interfaces, Library APIs, #ifdef etc. I think it's up to the maintainer of the module in question to decide how to handle portability. [2] : FWIW, GVolumeMonitor and related APIs is a *great* example of how to handle portability. We've kept the same application-level API since the beginning and have managed to just swap the implementation out (hal, udisks1 and now udisks2) without disrupting any application. And we've made sure it worked on old-skool Unix and the BSDs by having a 'unix' (e.g. fstab/mtab based) backend as well. But as any GIO/GVfs developer will tell you, the price is pretty high but in terms of code complexity and also there's a hit in runtime/login performance because of its distributed nature. There's another important lesson to be learned here: portability and abstractions on the GNOME-side is not only about OS portability - it also makes it easier to revamp some of the underlying subsystems ... e.g. I could never have done the hal-udisks1-udisks2 move without something like GVolumeMonitor so, in retrospect, it turned out to be a good idea that such abstractions were around. But they come at a cost. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
David: On 10/22/12 11:50 AM, David Zeuthen wrote: On Mon, Oct 22, 2012 at 11:18 AM, Brian Cameron brian.came...@oracle.com wrote: You are talking about shipping a *complete* and *free* (libre *and* gratis) graphical desktop environment and you're complaining that you have to spend a couple of hours *reviewing* the code and/or turning off the features that you *did not* participate in developing because you choose to use a different OS than the people who actually *did* spend time working on the feature? I have heard about this couple of hours. Is it even possible to build the GNOME stack in 2 hours if you run into no problems? I don't think that's fair at all - and I really have to constrain myself to not use stronger language here. I never intended to complain. I was only saying that I find it not surprising that things are moving slowly considering the state of documentation. That is just my perspective. If it is necessary to point the blame at anyone, perhaps the right people to blame are, as you suggest, the people who are being slow. That said, I do think the GNOME Foundation does play a role in trying to ensure that there is good communication and coordination across distros, so I think it is equally wrong to suggest that the responsibility of moving forward lies solely in the hands of the distros. Are you suggesting that The GNOME Foundation and community should play no role in making the GNOME 3 transition a success across distros? Instead, may I suggest getting involved early and voicing your concern *during development* so we can either add an abstractions (such as e.g. GVolumeMonitor, GDrive, GVolume, GMount) or ifdefs or whatever [1] and avoid situations like this? I have, over the past years, tried several times to discuss issues surrounding portability. For example, as GDM maintainer I strongly recommended against supporting ConsoleKit as a hard dependency in the first place. In hindsight, I think adopting and throwing away ConsoleKit was not the best decisions. In the situations where I did voice my concerns during development, I did not get the impression that my concerns generated much response. Surely, the way it needs to work in GNOME is that if distributors show up and do portability-work (and it's good enough) [2] it will get merged. But it involves actually showing up and doing the work and not just sending e-mail. I have personally done a fair share of porting work over the years. I do not just send emails. Have we not met? But please don't expect others to port GNOME to run on your OS. I was never suggesting that any others do any sort of port for anyone. I was only highlighting that the lack of documentation makes things slow. I am sure that we can improve the situation with some effort. Many mature products provide docuemntation to help developers make a transition when there is a new major release. I think GNOME is weak in this area. The fact that GNOME's developer documentation and GUI building tools are weak is not a new topic. Last year I remember people talking about how to catch up with KDE in this regards, for example. Unfortunately, I do not think we have yet even accomplished this more modest target. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Hey, On Mon, Oct 22, 2012 at 1:24 PM, Brian Cameron brian.came...@oracle.com wrote: I have heard about this couple of hours. Is it even possible to build the GNOME stack in 2 hours if you run into no problems? That's not the point. The point is that adapting GNOME to some OS such as Solaris, Fedora, Ubuntu, OpenBSD or whatever is likely to take a lot more effort than a couple of hours each release. The point is that it's not fair to anyone if a *OS vendor* to expect this to be easy and complain if it's not saying there's not enough documentation or it doesn't fit in with our schedule. I have, over the past years, tried several times to discuss issues surrounding portability. For example, as GDM maintainer I strongly recommended against supporting ConsoleKit as a hard dependency in the first place. In hindsight, I think adopting and throwing away ConsoleKit was not the best decisions. In the situations where I did voice my concerns during development, I think we have seen that these two ideas 1. make GNOME depend on a system daemon and port it everywhere (HAL, ConsoleKit, for example) 2. make GNOME depend on a system-bus based D-Bus API and make it work with several implementations (systemd, upstart, for example) do not work well in practice. But we didn't know back then, things like HAl and ConsoleKit all sounded like great ideas! The thing is that these are the kind of mistakes that we as a project had to make *ourselves* - it's not something you can just learn. In that way, failing is *good* - you learn new things from it. As a project, I think GNOME learnt a bunch from it. FWIW, what seems to work a lot better is to do the abstraction on the GNOME-side, e.g. GVolumeMonitor, GNetworkMonitor and so on and then leave it to OSes to fill that in. I did not get the impression that my concerns generated much response. Dude, that happens to all of us at some point. I have personally done a fair share of porting work over the years. I do not just send emails. Have we not met? We have. But I was making a more broad comment but of course: your effort is very much appreciated. As is, for example, Antoine's work on OpenBSD portability. Or the work going into taking advantage of certain systemd features. Work on GNOME is *always* appreciated and we don't discriminate based on what OS your are using. But it does require the work to happen - not so much a long thread about how it's so much work and how it's hard and so on. But please don't expect others to port GNOME to run on your OS. I was never suggesting that any others do any sort of port for anyone. I was only highlighting that the lack of documentation makes things slow. I am sure that we can improve the situation with some effort. Many mature products provide docuemntation to help developers make a transition when there is a new major release. I think GNOME is weak in this area. The fact that GNOME's developer documentation and GUI building tools are weak is not a new topic. Last year I remember people talking about how to catch up with KDE in this regards, for example. Unfortunately, I do not think we have yet even accomplished this more modest target. Nah, I really don't think GNOME should be that complicated - we're a desktop, we're a user experience - we should be more fluid, more agile than your grandfather's SDK porting kits with committees (or, worse, mailing lists) having to approve this or that thing. I mean, it's fine to have this for GLib and GTK+ (and we do [1]) but I wouldn't want to see us spend that amount of time on GNOME proper - I'd much much rather see us spend time on improving GNOME or adding cool features. David [1] : http://developer.gnome.org/gio/unstable/migrating.html [2] : http://developer.gnome.org/gtk3/unstable/migrating.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
David: On 10/22/12 01:01 PM, David Zeuthen wrote: But please don't expect others to port GNOME to run on your OS. I was never suggesting that any others do any sort of port for anyone. I was only highlighting that the lack of documentation makes things slow. I am sure that we can improve the situation with some effort. Many mature products provide docuemntation to help developers make a transition when there is a new major release. I think GNOME is weak in this area. The fact that GNOME's developer documentation and GUI building tools are weak is not a new topic. Last year I remember people talking about how to catch up with KDE in this regards, for example. Unfortunately, I do not think we have yet even accomplished this more modest target. Nah, I really don't think GNOME should be that complicated - we're a desktop, we're a user experience - we should be more fluid, more agile than your grandfather's SDK porting kits with committees (or, worse, mailing lists) having to approve this or that thing. I mean, it's fine to have this for GLib and GTK+ (and we do [1]) but I wouldn't want to see us spend that amount of time on GNOME proper - I'd much much rather see us spend time on improving GNOME or adding cool features. Right. So, you probably are not surprised that things are moving along slowly either. :) Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Hey, On Mon, Oct 22, 2012 at 2:05 PM, Brian Cameron brian.came...@oracle.com wrote: Right. So, you probably are not surprised that things are moving along slowly either. :) Actually I'm quite excited about the development pace for GNOME nowadays - there are lots of cool *user-visible* features landing in new releases. The fact that it's hard for some OSes to keep up is an interesting indicator that the focus in GNOME is more on features than (boring [1]) abstraction / portability work. I'm not saying that's 100% right - in fact, my previous mails calls for help in that area - but as an end-user, I'm pretty excited about GNOME. I would definitely not characterize it as moving along slowly. As a developer (and working for an OS vendor), I *do* want more OS vendors to step up and intensify their participation in the project. Yes, more participation from several different OS vendors might slow down feature development a bit (for example, landing a *simple* library-based abstraction for systemd's logind mechanism), but at the end of the day, it's probably going to be a win for everyone. David [1] : I'm entitled to label it this way because I've done a lot of this kind of work - it really is not very exciting or sexy :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
David: On 10/22/12 01:17 PM, David Zeuthen wrote: On Mon, Oct 22, 2012 at 2:05 PM, Brian Cameronbrian.came...@oracle.com wrote: Right. So, you probably are not surprised that things are moving along slowly either. :) Actually I'm quite excited about the development pace for GNOME nowadays - there are lots of cool *user-visible* features landing in new releases. The fact that it's hard for some OSes to keep up is an interesting indicator that the focus in GNOME is more on features than (boring [1]) abstraction / portability work. I'm not saying that's 100% right - in fact, my previous mails calls for help in that area - but as an end-user, I'm pretty excited about GNOME. I would definitely not characterize it as moving along slowly. I agree that the GNOME development pace is exciting. I was talking more about porting efforts moving along slowly. Though I am not sure that either one really needs to be fully at the expense of the other. As a developer (and working for an OS vendor), I *do* want more OS vendors to step up and intensify their participation in the project. Yes, more participation from several different OS vendors might slow down feature development a bit (for example, landing a *simple* library-based abstraction for systemd's logind mechanism), but at the end of the day, it's probably going to be a win for everyone. While the current pace might be good enough, if a little more planning could avoid so much interface churn where interfaces are developed than soon thrown away, then that planning would actually speed up development rather than slow it down. I do not think the GNOME community has yet found the sweet spot here, though others may disagree. When an upstream FOSS community re-invents the wheel too much, it is tiring and encourages a more wait-and-see attitude, and actually discourages healthier cross-distro participation. Whether this is a good or bad thing is probably hard to say without more hindsight. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Bastien Nocera wrote: Additionally, and separately, support for ConsoleKit usage for session-tracking will be removed. This is now pushed to master for 3.7.1. Well, this all happened a few days before the release deadline, this is not easy matter, we have a release team meeting this week-end and we will talk about the whole situation. Of course this is still just 3.7.1, but anyway. I'd suggest we do *not* ship gnome-settings-daemon 3.7.1 in GNOME 3.7.1 and wait for a project-wide decisionon how support of ConsoleKit systems should be (dis)continued. Fred [1] those kind of decisions were the subject of the release team part our AGM in GUADEC... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Mon, 2012-10-22 at 14:17 -0400, David Zeuthen wrote: As a developer (and working for an OS vendor), I *do* want more OS vendors to step up and intensify their participation in the project. Yes, more participation from several different OS vendors might slow down feature development a bit (for example, landing a *simple* library-based abstraction for systemd's logind mechanism), but at the end of the day, it's probably going to be a win for everyone. A library abstraction for systemd's logind mechanism that provides a fallback to non-systemd backend(s) is something that I am certainly interested in, and am willing to help create, if it would prevent gnome-3.8 from having a hard dependency on systemd. First, we need to figure out what functionality the consumers of such a library would require. So far, I see the following: 1. suspend / hibernate / poweroff / reboot 2. a prepare-for-suspend/poweroff signal 3. a power management inhibit mechanism that wraps http://www.freedesktop.org/wiki/Software/systemd/inhibit Is there anything else that would be needed? -Alexandre ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Mon, 2012-10-22 at 17:38 -0400, Alexandre Rostovtsev wrote: 1. suspend / hibernate / poweroff / reboot The challenge is that it's not just about an API call which ends up as executing /usr/sbin/reboot or some other platform-specific mechanism. It's about modeling state. The canonical bug I use when describing the value in the tight GNOME/logind integration is stuff like pressing shutdown in the UI, then closing the laptop lid and having the system unexpectedly suspend in the middle of shutdown. Left hand unaware of what right hand is doing sort of bug. Really the only way to fix these kinds of things is to have one component of the system managing state, or at least multiple components that are tightly coordinated. Anyways, the best starting point for this is probably gnome-session's gsm-system.h, which already wraps a lot of things. Stuff like the inhibitors is stubbed out for ConsoleKit, but that's fine, it's not regressing anything. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Mon, 2012-10-22 at 11:02 -0400, Colin Walters wrote: On Mon, 2012-10-22 at 14:04 +0200, Bastien Nocera wrote: My mistake, that's because the old (ifdef'ed) code used it. The D-Bus interface[1] provides the same functionality[2]. I'll take patches to make it use the D-Bus interface. Right, ok rather than that, I can take over maintaining this bit of code for now. Sorry, but I don't consider moving it to gnome-desktop to be taking over maintenance. I'll end up doing bug fixing there just as I am now. I don't see how this helps. The code just lives somewhere that's still within view (gnome-desktop isn't some magic module where things get hidden), gnome-settings-daemon's power plugin still requires logind to work, and gnome-shell with upower/ConsoleKit will likely behave brokenly (given that there's no gnome-settings-daemon counter-part). Here's patches to move it to gnome-desktop, and update gnome-settings-daemon to depend on it: gnome-desktop: https://bugzilla.gnome.org/show_bug.cgi?id=686649 gnome-settings-daemon: https://bugzilla.gnome.org/show_bug.cgi?id=686650 What's the sudden attachment to ConsoleKit? You could just as easily 1) port to g-s-d logind code to use D-Bus, and write a shim on top of ConsoleKit that would export a similar API. That means that users of that API could make use of advanced features of logind when required, and not have this exact same conversation about whether ConsoleKit should still be supported. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Mon, 2012-10-22 at 10:18 -0500, Brian Cameron wrote: Bastien: I was not trying to suggest that there was no GNOME portability documentation. Instead I was saying that it should not be surprising that non-Linux distros (and many popular Linux distros) are making very slow progress with GNOME 3 based on the quality and scope of the existing documentation. https://live.gnome.org/PortabilityMatrix The Portability Matrix you highlight is a good example of this. The matrix highlights that some distros use different solutions for various features, but no information is provided to help any distro know what should be considered when making decisions. Most of the rows in the matrix assume that the reader already understands what is even being described. For example, the matrix highlights that gsd power features use logind. Most readers would likely need to review the code to understand what specific power features are actually being described here or why they might need logind. Most rows in the table are like this, so this matrix is only a very useful guide if the reader has many hours to invest to understand how the information applies to them. To me, the matrix looks more like a draft of an outline to a guide, but it is a start. You expect somebody to not invest any time learning about the technologies we use, and then replace them? The code's there for everybody to see, unlike the Sun Ray's code. The people porting that code should certainly be putting some effort in understanding the technologies before getting decisions about whether it should be supported. On 10/22/12 01:15 AM, Bastien Nocera wrote: On Fri, 2012-10-19 at 13:33 -0500, Brian Cameron wrote: The GNOME community provides little guidance about what systemd interfaces are actually needed for various GNOME features to work properly. Maybe nobody really knows yet, but non-Linux distros will likely make slow progress as long as there is so little good guidance. This page: https://live.gnome.org/PortabilityMatrix was created for that purpose 6 months ago. Considering GNOME 3.6 is out the door, 6 months ago seems already quite late to be providing guides on how to port to GNOME 3, but late is better than never. The page was created in 2010, and it's a Wiki. Only 2 people handling non-Linux filled it up (that would be Antoine for OpenBSD and Tor for Windows). Where's all the Solaris hackers updating the Wiki? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Sat, 20.10.12 09:21, Jasper St. Pierre (jstpie...@mecheye.net) wrote: (Somehow you manage to reply with Florian Max@gmail, Florian Mullner@gmail, and Florian Muller@gnome. I won't question it) On Fri, Oct 19, 2012 at 1:15 PM, Florian Müllner fmuell...@gnome.org wrote: On Fri, Oct 19, 2012 at 7:10 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: This is what I feel. DBus is our system abstraction layer. I feel that making ConsoleKit support the logind interface wouldn't be that big of a patch and solve this issue, at least. Unless I'm mistaken ConsoleKit only provides a subset of logind's functionality though. logind provides the union of UPower and ConsoleKit, no? I wonder if it would make sense to have a separate org.freedesktop.powerd interface that UPower would provide, then. logind only took over calls to suspend/hibernate the machine from upower. Stuff like battery management and suchlike remains in upower and doesn't belong in logind. logind never was intended to be an abstraction layer of any kind. In the contrary, in order to keep the stack thin we export a lot of things that do not really apply to non-Linux, or are hard to translate. That's stuff like the cgroup path we expose for sessions, but plays much farther into the logic even, in that we build on the Linux audit framework, or expose calls such as GetSessionByPID() which securely determine the session ID of a PID. Something like that is hard to implement if the underlying OS doesn't have anything like cgroups which allows us to attach a session id safely and securely to processes and where unprivileged processes cannot escape. We also implement multi-seat based on udev device paths and that's directly visible in the API. Then, logind hooks into the handling of the ACPI keys and things like that, which might have counterparts on other Unixes, but not obvious ones (and the key handling *is* actually exposed in the API). The low-level C API we expose (which can be used as more lightwight, passive way to watch session/user/seat states in addition to D-Bus) exposes concepts as systemd unit names, and is built around inotify. And the list goes on... Some of these APIs could be turned into NOPs on non-Linux, or faked, or one could find alternatives for. But the gist simply is: logind and its APIs is not portable to non-Linux really. It never was intended to be. When we started to work on it we tried to figure out what precisely we wanted to do with logind, and one of the first things we found was that multi-seat should work right-away, and not be an afterthought. If you think about that, then you are in device management land. And if you are in device management land, then portability is a foreign country. So yupp, I am sorry to say, but logind is something that is in both code and API Linux-specific (heck, even systemd-specific), and porting it to other systems will necessarily be a painful. Note that many of the other APIs we came up with in the systemd context are actually designed to be mostly portable to other Linuxes/Unixes, for example hostnamed, timedated and localed, because it was easy there, and there was no reason to break portability of the APIs, but for logind this didn't appear like a good option for us, if we wanted to get the Linux story right. For a list of the interfaces systemd and the portability of them we have this list BTW: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart If portability matters for tracking seats/sessions/logins, yadda yadday, then it has to take place at the client side I am sure. logind's bus interfaces and C interfaces are not the right place. Sorry. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Le vendredi 19 octobre 2012, à 12:07 -0400, Colin Walters a écrit : On Fri, 2012-10-19 at 15:48 +0200, Bastien Nocera wrote: I would recommend that gnome-shell uses systemd to suspend, and I would recommend gnome-shell, gnome-session and gdm also drop their ConsoleKit session tracking code. At the end of the day, the decisions are not mine to make, so if the costs of keeping those options are low enough for you, then feel free to keep them. But in reality, the set of git repositories forms a whole. And if gnome-settings-daemon doesn't support !systemd, then the whole doesn't either. So if you decide to delete this code from g-s-d, it makes the work of anyone else completely pointless. Broadly speaking, I don't think it makes sense for this to be up to individual module maintainers as they please, because the result is incoherent. +1. This is exactly the kind of stuff that, at least from my perspective, was raised during the AGM at GUADEC. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
(Somehow you manage to reply with Florian Max@gmail, Florian Mullner@gmail, and Florian Muller@gnome. I won't question it) On Fri, Oct 19, 2012 at 1:15 PM, Florian Müllner fmuell...@gnome.org wrote: On Fri, Oct 19, 2012 at 7:10 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: This is what I feel. DBus is our system abstraction layer. I feel that making ConsoleKit support the logind interface wouldn't be that big of a patch and solve this issue, at least. Unless I'm mistaken ConsoleKit only provides a subset of logind's functionality though. logind provides the union of UPower and ConsoleKit, no? I wonder if it would make sense to have a separate org.freedesktop.powerd interface that UPower would provide, then. Is there anything else? Florian -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Requiring systemd for the gnome-settings-daemon power plugin
Hello, I intend on making systemd a hard requirement for the power plugin in gnome-settings-daemon. There is a lot of interactions and external factors involved in making policy decision about power. This makes the power plugin one of the more fragile parts of the system, with things like DPMS, screensaver activation, screen locking, brightness control, suspend policy, battery information exporting, all handled in the same codebase. Using systemd to request suspends means that: - things work out of the box when people do not use GNOME (no need to install acpid which then conflicts with GNOME) - inhibitions are per-system instead of per-user - application get more information about suspending - simplify the power plugin's codebase a great deal The patches I will commit are here: https://bugzilla.gnome.org/show_bug.cgi?id=680689 Additionally, and separately, support for ConsoleKit usage for session-tracking will be removed. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, Oct 19, 2012 at 11:00:05AM +0200, Bastien Nocera wrote: Hello, I intend on making systemd a hard requirement for the power plugin in gnome-settings-daemon. There is a lot of interactions and external factors involved in making policy decision about power. This makes the power plugin one of the more fragile parts of the system, with things like DPMS, screensaver activation, screen locking, brightness control, suspend policy, battery information exporting, all handled in the same codebase. Using systemd to request suspends means that: - things work out of the box when people do not use GNOME (no need to install acpid which then conflicts with GNOME) - inhibitions are per-system instead of per-user - application get more information about suspending - simplify the power plugin's codebase a great deal The patches I will commit are here: https://bugzilla.gnome.org/show_bug.cgi?id=680689 Additionally, and separately, support for ConsoleKit usage for session-tracking will be removed. I think at one point the GNOME project will need to step up and explicitely states that GNOME is a Linux-only Desktop. I am a BSD user; don't get me wrong, if GNOME goes Linux-only then so be it. But the current situation is hard for us because it is unclear where all of this is going. When systemd was first mentionned on the lists, it was said it wouldn't be a hard requirement. Fair enough, we are only talking about the power plugin here but the way it is going systemd will soon be needed for more important features. I'm just wondering if it is still worth trying to maintain GNOME for !linux platforms (like I do on OpenBSD). Implementing some of what systemd provides is far from trivial for us. To summarize, it'd be nice to know whether there is still a chance to see GNOME running on BSD in a near future. If everything is going systemd, then the answer is clear, but for now I lack the information. Thanks. -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, Oct 19, 2012 at 5:14 AM, Antoine Jacoutot ajacou...@gnome.org wrote: I think at one point the GNOME project will need to step up and explicitely states that GNOME is a Linux-only Desktop. I am a BSD user; don't get me wrong, if GNOME goes Linux-only then so be it. But the current situation is hard for us because it is unclear where all of this is going. When systemd was first mentionned on the lists, it was said it wouldn't be a hard requirement. Fair enough, we are only talking about the power plugin here but the way it is going systemd will soon be needed for more important features. I'm just wondering if it is still worth trying to maintain GNOME for !linux platforms (like I do on OpenBSD). Implementing some of what systemd provides is far from trivial for us. To summarize, it'd be nice to know whether there is still a chance to see GNOME running on BSD in a near future. If everything is going systemd, then the answer is clear, but for now I lack the informationit Hey Antoine, I think there's a good chance for GNOME running on BSD, thanks to people like you who keep things working. I can imagine it feels like a sysiphus job at times - I hope you get thank-you letters from BSD/GNOME users every now and then... Bastien is speaking as the gnome-settings-daemon maintainer, and I can understand why he wants to get rid of the complicated maze of talk-to-upower-or-to-consolekit-or-to-systemd. It is his decision to make in the end, but there is certainly enough time between now and 3.8 to evaluate the best way to keep things working on BSD, no need to throw in the towel now. As for GNOME speaking up, the release team has produced this document: https://live.gnome.org/ReleasePlanning/WhatWeRelease in an attempt to clarify our position. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, Oct 19, 2012 at 4:00 PM, Bastien Nocera had...@hadess.net wrote: Hello, I intend on making systemd a hard requirement for the power plugin in gnome-settings-daemon. Does it mean GNOME without systemd does not support power management anymore? If so, any chance an external power plugin, maintained separately, can be added to restore power management? -- Duy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 18:51 +0700, Nguyen Thai Ngoc Duy wrote: On Fri, Oct 19, 2012 at 4:00 PM, Bastien Nocera had...@hadess.net wrote: Hello, I intend on making systemd a hard requirement for the power plugin in gnome-settings-daemon. Does it mean GNOME without systemd does not support power management anymore? If so, any chance an external power plugin, maintained separately, can be added to restore power management? It's certainly possible, but it's not something I'll work on. Note that I also intend on dropping session tracking support from ConsoleKit. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, Oct 19, 2012 at 8:05 AM, Bastien Nocera had...@hadess.net wrote: On Fri, 2012-10-19 at 18:51 +0700, Nguyen Thai Ngoc Duy wrote: On Fri, Oct 19, 2012 at 4:00 PM, Bastien Nocera had...@hadess.net wrote: Hello, I intend on making systemd a hard requirement for the power plugin in gnome-settings-daemon. Does it mean GNOME without systemd does not support power management anymore? If so, any chance an external power plugin, maintained separately, can be added to restore power management? It's certainly possible, but it's not something I'll work on. Note that I also intend on dropping session tracking support from ConsoleKit. I was actually looking earlier - what do we actually use 'session tracking' for in gsd, other than power management ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Hello Antoine, On Fri, 2012-10-19 at 11:14 +0200, Antoine Jacoutot wrote: On Fri, Oct 19, 2012 at 11:00:05AM +0200, Bastien Nocera wrote: Hello, I intend on making systemd a hard requirement for the power plugin in gnome-settings-daemon. There is a lot of interactions and external factors involved in making policy decision about power. This makes the power plugin one of the more fragile parts of the system, with things like DPMS, screensaver activation, screen locking, brightness control, suspend policy, battery information exporting, all handled in the same codebase. Using systemd to request suspends means that: - things work out of the box when people do not use GNOME (no need to install acpid which then conflicts with GNOME) - inhibitions are per-system instead of per-user - application get more information about suspending - simplify the power plugin's codebase a great deal The patches I will commit are here: https://bugzilla.gnome.org/show_bug.cgi?id=680689 Additionally, and separately, support for ConsoleKit usage for session-tracking will be removed. I think at one point the GNOME project will need to step up and explicitely states that GNOME is a Linux-only Desktop. GNOME is a desktop that requires interfaces that only exist on Linux so far. It's where most of the development is done, and it's also where most the majority of users are. I am a BSD user; don't get me wrong, if GNOME goes Linux-only then so be it. But the current situation is hard for us because it is unclear where all of this is going. When systemd was first mentionned on the lists, it was said it wouldn't be a hard requirement. Fair enough, we are only talking about the power plugin here but the way it is going systemd will soon be needed for more important features. I'm just wondering if it is still worth trying to maintain GNOME for ! linux platforms (like I do on OpenBSD). Implementing some of what systemd provides is far from trivial for us. To summarize, it'd be nice to know whether there is still a chance to see GNOME running on BSD in a near future. If everything is going systemd, then the answer is clear, but for now I lack the information. If the logind D-Bus interfaces for inhibition[1] and session tracking[2] are implemented then gnome-settings-daemon will work on OpenBSD or other operating systems. There might be, or there will be, more changes, I would expect, that will make running GNOME on non-Linux require more work (all the work on application sandboxing[3] for example). Whether you choose to carry on the work is really up to the communities in question, and you. I hope you will, but as a maintainer, I cannot carry supporting a myriad of options and infrastructures. Cheers [1]: http://www.freedesktop.org/wiki/Software/systemd/inhibit [2]: http://www.freedesktop.org/wiki/Software/systemd/logind [3]: https://live.gnome.org/GnomeOS/Design/Whiteboards/Sandboxing ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 08:49 -0400, Matthias Clasen wrote: On Fri, Oct 19, 2012 at 8:05 AM, Bastien Nocera had...@hadess.net wrote: On Fri, 2012-10-19 at 18:51 +0700, Nguyen Thai Ngoc Duy wrote: On Fri, Oct 19, 2012 at 4:00 PM, Bastien Nocera had...@hadess.net wrote: Hello, I intend on making systemd a hard requirement for the power plugin in gnome-settings-daemon. Does it mean GNOME without systemd does not support power management anymore? If so, any chance an external power plugin, maintained separately, can be added to restore power management? It's certainly possible, but it's not something I'll work on. Note that I also intend on dropping session tracking support from ConsoleKit. I was actually looking earlier - what do we actually use 'session tracking' for in gsd, other than power management ? The color, power, and automounter plugins all use CK/systemd for session tracking. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Le 19/10/2012 11:00, Bastien Nocera a écrit : I intend on making systemd a hard requirement Hey Bastien, Was there any consideration to define those interface as standard freedesktop interfaces to let GNOME work on any system implementing those? Some distributions (Debian, Ubuntu, ...) don't use nor plan to use systemd, your decision basically means those options for those distributions: - keep the current version of gnome-settings-daemon - distro patch/fork g-s-d to keep supporting non systemd systems - stop shipping GNOME Which one do you envision distributions opting for there? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 15:05 +0200, Sebastien Bacher wrote: Le 19/10/2012 11:00, Bastien Nocera a écrit : I intend on making systemd a hard requirement Hey Bastien, Was there any consideration to define those interface as standard freedesktop interfaces to let GNOME work on any system implementing those? Some distributions (Debian, Ubuntu, ...) don't use nor plan to use systemd, your decision basically means those options for those distributions: - keep the current version of gnome-settings-daemon - distro patch/fork g-s-d to keep supporting non systemd systems - stop shipping GNOME Which one do you envision distributions opting for there? I don't see non-systemd Linux distributions as being different from OpenBSD, or other Unix systems. If you want to provide compatible interfaces to systemd without using systemd, then you'll need to engage with the systemd developers to make sure that APIs are suitable for your implementation. I don't plan on doing that work, as it would just use up the time I'd freed up by not having to maintain 2 separate versions of the power plugin and session tracking code. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Le 19/10/2012 15:23, Bastien Nocera a écrit : If you want to provide compatible interfaces to systemd without using systemd, then you'll need to engage with the systemd developers to make sure that APIs are suitable for your implementation. No, I don't plan to do that work either so I will take from it that GNOME is not interested by being distributed on e.g Ubuntu anymore. I will take note about that and it's a topic we will discuss at next UDS, let's see if the GNOME remix effort who started recently has people motivated by doing that work, otherwise I will suggest we stop making GNOME available since Ubuntu doesn't have the requirements to run 3.8... Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On vie, 2012-10-19 at 14:55 +0200, Bastien Nocera wrote: On Fri, 2012-10-19 at 08:49 -0400, Matthias Clasen wrote: On Fri, Oct 19, 2012 at 8:05 AM, Bastien Nocera had...@hadess.net wrote: Note that I also intend on dropping session tracking support from ConsoleKit. I was actually looking earlier - what do we actually use 'session tracking' for in gsd, other than power management ? The color, power, and automounter plugins all use CK/systemd for session tracking. Sounds like gnome-shell will be affected as well then. Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, Oct 19, 2012 at 9:27 AM, Sebastien Bacher seb...@ubuntu.com wrote: Le 19/10/2012 15:23, Bastien Nocera a écrit : If you want to provide compatible interfaces to systemd without using systemd, then you'll need to engage with the systemd developers to make sure that APIs are suitable for your implementation. No, I don't plan to do that work either so I will take from it that GNOME is not interested by being distributed on e.g Ubuntu anymore. I will take note about that and it's a topic we will discuss at next UDS, let's see if the GNOME remix effort who started recently has people motivated by doing that work, otherwise I will suggest we stop making GNOME available since Ubuntu doesn't have the requirements to run 3.8... I don't think that is a very productive way to have a discussion. What are you hoping to achieve ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 15:30 +0200, Florian Max wrote: On vie, 2012-10-19 at 14:55 +0200, Bastien Nocera wrote: On Fri, 2012-10-19 at 08:49 -0400, Matthias Clasen wrote: On Fri, Oct 19, 2012 at 8:05 AM, Bastien Nocera had...@hadess.net wrote: Note that I also intend on dropping session tracking support from ConsoleKit. I was actually looking earlier - what do we actually use 'session tracking' for in gsd, other than power management ? The color, power, and automounter plugins all use CK/systemd for session tracking. Sounds like gnome-shell will be affected as well then. I would recommend that gnome-shell uses systemd to suspend, and I would recommend gnome-shell, gnome-session and gdm also drop their ConsoleKit session tracking code. At the end of the day, the decisions are not mine to make, so if the costs of keeping those options are low enough for you, then feel free to keep them. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, Oct 19, 2012 at 07:43:26AM -0400, Matthias Clasen wrote: On Fri, Oct 19, 2012 at 5:14 AM, Antoine Jacoutot ajacou...@gnome.org wrote: I think at one point the GNOME project will need to step up and explicitely states that GNOME is a Linux-only Desktop. I am a BSD user; don't get me wrong, if GNOME goes Linux-only then so be it. But the current situation is hard for us because it is unclear where all of this is going. When systemd was first mentionned on the lists, it was said it wouldn't be a hard requirement. Fair enough, we are only talking about the power plugin here but the way it is going systemd will soon be needed for more important features. I'm just wondering if it is still worth trying to maintain GNOME for !linux platforms (like I do on OpenBSD). Implementing some of what systemd provides is far from trivial for us. To summarize, it'd be nice to know whether there is still a chance to see GNOME running on BSD in a near future. If everything is going systemd, then the answer is clear, but for now I lack the informationit Hey Antoine, I think there's a good chance for GNOME running on BSD, thanks to people like you who keep things working. I can imagine it feels like a sysiphus job at times - I hope you get thank-you letters from BSD/GNOME users every now and then... Actually I do, yes :) Bastien is speaking as the gnome-settings-daemon maintainer, and I can understand why he wants to get rid of the complicated maze of talk-to-upower-or-to-consolekit-or-to-systemd. It is his decision to make in the end, but there is certainly enough time between now and 3.8 to evaluate the best way to keep things working on BSD, no need to throw in the towel now. Sure, but my initial concern is that once you have one foot in systemd, why not embrace it totally? If we are talking about implementing a couple of systemd interfaces, fine. If the end goal is to need most of systemd to have a working Desktop environment then I am very much concerned and would love to know about it. Note that my concern is very selfish I agree, I am using GNOME not just as a personnal Desktop but also maintain several thousands installations. That's why I am even more interested about the direction it is going. The way I see it is that people were depending on somewhat proven portable technologies (for the most part) and the arrival of systemd now splits the community. I don't see systemd as just another dependency, it's deeper than that because it aggregates lots of things that could originally be into separate projects. Don't see this as a rant against systemd, it's not; I'm just confused a Desktop environment has to depend on such specific low-level software. If I want to explain it in a very stupid way: why does an init/cron/syslog/... replacement is needed to change a timezone or track user sessions? It's not, probably. But the problem is that systemd implements lots of these things, it's not the fault of the GNOME project of course, but if some of the interfaces were actually separated from systemd, it would make it way easier for distributions or BSD systems that don't use systemd to implement them and submit portability patches (which are not accepted in systemd itself anyway). Since this is not the case, I am a bit disappointed that GNOME relies on such interfaces... Hopefully my mail will not be seen as a dumb rant, I just wanted to express and explain some of the frustration I have experienced ;-) As for GNOME speaking up, the release team has produced this document: https://live.gnome.org/ReleasePlanning/WhatWeRelease in an attempt to clarify our position. Hmm, I actually never noticed that before, thanks! -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 15:48 +0200, Bastien Nocera wrote: I would recommend that gnome-shell uses systemd to suspend, and I would recommend gnome-shell, gnome-session and gdm also drop their ConsoleKit session tracking code. At the end of the day, the decisions are not mine to make, so if the costs of keeping those options are low enough for you, then feel free to keep them. But in reality, the set of git repositories forms a whole. And if gnome-settings-daemon doesn't support !systemd, then the whole doesn't either. So if you decide to delete this code from g-s-d, it makes the work of anyone else completely pointless. Broadly speaking, I don't think it makes sense for this to be up to individual module maintainers as they please, because the result is incoherent. Now, this is obviously not a new debate. One option which I'd like to preserve at least is that !systemd platforms are able to build and run GNOME in basic window management mode. Basically the equivalent of thin client/remote X display. So we could say we don't support power management for example. In that case, you could support being compiled without systemd support (at present), and just do nothing if it doesn't exist. Or it could be runtime detection. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, Oct 19, 2012 at 3:48 PM, Bastien Nocera had...@hadess.net wrote: On Fri, 2012-10-19 at 15:30 +0200, Florian Max wrote: On vie, 2012-10-19 at 14:55 +0200, Bastien Nocera wrote: On Fri, 2012-10-19 at 08:49 -0400, Matthias Clasen wrote: On Fri, Oct 19, 2012 at 8:05 AM, Bastien Nocera had...@hadess.net wrote: Note that I also intend on dropping session tracking support from ConsoleKit. That sounds to me like we won't be able to keep using the current CK path for session tracking - I'm most certainly against reimplementing removed CK bits in gnome-shell. I would recommend that gnome-shell uses systemd to suspend Yeah, we should probably do that - filed as bug 686482. and I would recommend gnome-shell, gnome-session and gdm also drop their ConsoleKit session tracking code. At the end of the day, the decisions are not mine to make, so if the costs of keeping those options are low enough for you, then feel free to keep them. Well, it doesn't make much sense to run gnome-shell without gnome-settings-daemon. So if you change the latter to require either systemd or a dbus-compatible implementation, native CK support in the shell won't be too useful - in that sense, it *is* your decision :-) Note that I'm not complaining (I'm pretty sure the CK path is mostly untested nowadays until it reaches end users), just saying that I don't think we can consider g-s-d separately - a change like this will have implications for other modules as well. Regards, Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
The other thing we can do (and really should do) is share more code relating to systemd/CK and in general system abstractions. It's really pretty silly how hard we make it to share code between gnome-settings-daemon and gnome-shell. I'd be happy to move more stuff into to gnome-desktop personally. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On vie, 2012-10-19 at 12:19 -0400, Colin Walters wrote: The other thing we can do (and really should do) is share more code relating to systemd/CK and in general system abstractions. It's really pretty silly how hard we make it to share code between gnome-settings-daemon and gnome-shell. I'd be happy to move more stuff into to gnome-desktop personally. +1. And gnome-session has yet another systemd/CK abstraction. Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, Oct 19, 2012 at 12:19 PM, Colin Walters walt...@verbum.org wrote: The other thing we can do (and really should do) is share more code relating to systemd/CK and in general system abstractions. It's really pretty silly how hard we make it to share code between gnome-settings-daemon and gnome-shell. I'd be happy to move more stuff into to gnome-desktop personally. It is pretty ad hoc, currently. In some cases (such as power or randr), we have dbus interfaces, in others we share code in libraries (randr again, xkb, backgrounds), and we also copy some glue code around (user accounts come to mind). I'd caution that we don't really want 'abstractions', though. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, 2012-10-19 at 11:00 +0200, Bastien Nocera wrote: Hello, I intend on making systemd a hard requirement for the power plugin in gnome-settings-daemon. There is a lot of interactions and external factors involved in making policy decision about power. This makes the power plugin one of the more fragile parts of the system, with things like DPMS, screensaver activation, screen locking, brightness control, suspend policy, battery information exporting, all handled in the same codebase. Using systemd to request suspends means that: - things work out of the box when people do not use GNOME (no need to install acpid which then conflicts with GNOME) - inhibitions are per-system instead of per-user - application get more information about suspending - simplify the power plugin's codebase a great deal The patches I will commit are here: https://bugzilla.gnome.org/show_bug.cgi?id=680689 Could you please list the systemd interfaces, methods, properties, and signals that you are planning to use so that non-systemd distros can evaluate what to do? In Gentoo, for example, we need to decide whether it's feasible to create a sufficient non-systemd implementation of these interfaces on top of consolekit and acpid, or whether booting with systemd really will become a hard requirement for us in 2013. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, Oct 19, 2012 at 12:43 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Fri, Oct 19, 2012 at 12:19 PM, Colin Walters walt...@verbum.org wrote: The other thing we can do (and really should do) is share more code relating to systemd/CK and in general system abstractions. It's really pretty silly how hard we make it to share code between gnome-settings-daemon and gnome-shell. I'd be happy to move more stuff into to gnome-desktop personally. It is pretty ad hoc, currently. In some cases (such as power or randr), we have dbus interfaces, in others we share code in libraries (randr again, xkb, backgrounds), and we also copy some glue code around (user accounts come to mind). I'd caution that we don't really want 'abstractions', though. This is what I feel. DBus is our system abstraction layer. I feel that making ConsoleKit support the logind interface wouldn't be that big of a patch and solve this issue, at least. There's the issue with applications using systemd library directly, since that talks to the filesystem rather than DBus. I'd really like to see that changed, or at least have some shared client library that talks over DBus but I don't have any power to do that. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, Oct 19, 2012 at 7:10 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: This is what I feel. DBus is our system abstraction layer. I feel that making ConsoleKit support the logind interface wouldn't be that big of a patch and solve this issue, at least. Unless I'm mistaken ConsoleKit only provides a subset of logind's functionality though. Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Le 19/10/2012 15:41, Matthias Clasen a écrit : I don't think that is a very productive way to have a discussion. What are you hoping to achieve ? The discussion went this way: 1: g-s-d will drop non systemd support 2: could we define standard interface that are up to the distributor to implement rather than depends on systemd? an hard depends would mean those choices for non systemd distributors: list of options I could see 1: no, I don't intend to spend any time on that, if you don't want to use systemd you need to work with systemd upstream 2: ok, well I guess we need to think what to do then, but it's limiting our options to get GNOME shipped I'm not sure how unproductive it has been, it's merely stating intends and sharing concerns... What I'm hoping to achieve? I guess letting know GNOME, as a project, know in what position this choice put some of the distributors and what might be the outcome. It's sharing information and communicating ... is there any issue with that? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On 19 October 2012 14:27, Sebastien Bacher seb...@ubuntu.com wrote: ..otherwise I will suggest we stop making GNOME available since Ubuntu doesn't have the requirements to run 3.8... I'm sure I was talking to several people that managed to get systemd/logind working just fine on Ubuntu. Can't the GNOME remix just use systemd and the main spin just use upstart? Richard ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Some perspective about this issue from a Solaris perspective. On non-Linux systems like Solaris there is little value in using upstream GNOME code for some features. Power management is a good example. On Solaris, power management uses Solaris-specific interfaces and supports Solaris specific features. Solaris GNOME would never see much value in a general-purpose GUI for power management. Enterprise computing systems and clusters have unique power management needs compared to a laptop or desktop, and any upstream power management code is not going to consider how Solaris-specific virtualization features like zones (or Solaris Containers) affects power management. Most Solaris users use the desktop in a Sun Ray environment where they typically should not be setting the power management settings on their Sun Ray server anyway. So, Solaris probably does not care about this plugin much as long as it is possible to build GNOME without the feature and allows custom power management solutions to be integrated in some other reasonable way. Maybe BSD or other non-Linux distros cares about power management more? There is probably some cross-over between Solaris and BSD, and some differences like perhaps power management. There certainty are some systemd features that probably need to be made to work across all non-Linux systems to make GNOME work well. The systemd interfaces needed to make display management and the user session work, for example. Since the GNOME community seems disinterested in defining standard FreeDesktop interfaces for these features, perhaps it is necessary to develop some sort of bridge to make needed systemd functions work across non-Linux systems. The GNOME community provides little guidance about what systemd interfaces are actually needed for various GNOME features to work properly. Maybe nobody really knows yet, but non-Linux distros will likely make slow progress as long as there is so little good guidance. I do understand that the non-Linux GNOME community has to figure out the solutions to these problems by pulling themselves up by their bootstraps to a degree. That said, is it just me, or does it seem there is a harshly discouraging attitude about this amongst the community? Perhaps I am just reading too much into what seems a general lack of discussion about systemd decisions or interface migration? It seems I keep finding out about decisions after they seem to pretty much decided upon already. We might make better progress if we were even just a bit better about a more open and inclusive design process. I do know that amongst Solaris engineers there is an exhaustion of having to adopt, rewrite, and throw-away interfaces as often as the GNOME community seems to do. This does create resistance towards adopting the latest features. I do not mean to complain, though. Perhaps this sort of development style is just what is needed to compete in the vibrant and ever-shifting desktop market we face today. Not sure... Brian On 10/19/12 12:20 PM, Sebastien Bacher wrote: Le 19/10/2012 15:41, Matthias Clasen a écrit : I don't think that is a very productive way to have a discussion. What are you hoping to achieve ? The discussion went this way: 1: g-s-d will drop non systemd support 2: could we define standard interface that are up to the distributor to implement rather than depends on systemd? an hard depends would mean those choices for non systemd distributors: list of options I could see 1: no, I don't intend to spend any time on that, if you don't want to use systemd you need to work with systemd upstream 2: ok, well I guess we need to think what to do then, but it's limiting our options to get GNOME shipped I'm not sure how unproductive it has been, it's merely stating intends and sharing concerns... What I'm hoping to achieve? I guess letting know GNOME, as a project, know in what position this choice put some of the distributors and what might be the outcome. It's sharing information and communicating ... is there any issue with that? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Fri, Oct 19, 2012 at 06:25:05PM +0200, Florian Müllner wrote: On vie, 2012-10-19 at 12:19 -0400, Colin Walters wrote: The other thing we can do (and really should do) is share more code relating to systemd/CK and in general system abstractions. It's really pretty silly how hard we make it to share code between gnome-settings-daemon and gnome-shell. I'd be happy to move more stuff into to gnome-desktop personally. +1. And gnome-session has yet another systemd/CK abstraction. Speaking of which, has anyone done feasibility study on retiring gnome-session in favour of using systemd user instance? systemd has user instance support since the very beginning and it seem to be engineered as gnome-session replacement. And it's even being use in that role in Tizen... -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
