Re: Anyone going to be using ConsoleKit for 3.16 ?
Given that it's broken/removed in gnome-shell 3.16 and that there's been no feedback, I don't see the problem. We should have removed the support in concert, instead of different parts of GNOME doing it at different times, but the expectation already is that ConsoleKit support should be a downstream patch for most parts of GNOME. One more isn't going to hurt. That's the reason we reverted: https://git.gnome.org/browse/gnome-shell/commit/?id=a244c1e987502e359c45c0a9bc0012b5bc635553 in 3.14 for OpenBSD (and FreeBSD). -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone going to be using ConsoleKit for 3.16 ?
Okay guys, so what I'll do then is take the code out but post a patch to https://bugzilla.gnome.org/show_bug.cgi?id=743940 that adds it back. You guys can ship that with 3.16 and then drop it with 3.18 when LoginKit is integrated into your distros. That's awesome. Thanks a lot. -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone going to be using ConsoleKit for 3.16 ?
Hi Ray. Thanks a lot asking about this. OpenBSD *will* keep using ConsoleKit for 3.16. I expect that we should be able to be rid of it for 3.18 -- either using systembsd (far from ready) or the logind implementation that ConsoleKit2 is expected to provide iirc or ... something else. There are several other components of GNOME that still have some ConsoleKit support (at least in 3.14) and I would not mind removing such support for 3.16 if and only if reverting the removal is easy and not too intrusive. Not that I have a big say about it but... I forgot to mention that in its current form, GDM is broken by the way: https://bugzilla.gnome.org/show_bug.cgi?id=738691 The commit breaking CKit support was: https://git.gnome.org/browse/gnome-shell/commit/js/misc/loginManager.js?id=a244c1e987502e359c45c0a9bc0012b5bc635553 -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone going to be using ConsoleKit for 3.16 ?
On Fri, Jan 30, 2015 at 02:25:20PM -0500, Ray Strode wrote: Hey, I'm wondering if there are distros/platforms that are planning on using 3.16 and ConsoleKit together. I know there's LoginKit, systemd-shim and systembsd now that try to provide logind compatible interfaces for non-systemd systems, so I'd really like to get rid of the ConsoleKit code in GDM. The code is complicated and not really tested. I'm leaning toward getting rid of it in 3.16 (versus say 3.18). Distros, of course, could ship a patch to reverse to removal if necessary, so I don't think doing it for 3.16 should be too controversial, but I wanted to shoot a mail first anyway to gauge the reaction. Hi Ray. Thanks a lot asking about this. OpenBSD *will* keep using ConsoleKit for 3.16. I expect that we should be able to be rid of it for 3.18 -- either using systembsd (far from ready) or the logind implementation that ConsoleKit2 is expected to provide iirc or ... something else. There are several other components of GNOME that still have some ConsoleKit support (at least in 3.14) and I would not mind removing such support for 3.16 if and only if reverting the removal is easy and not too intrusive. Not that I have a big say about it but... -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Opening the 3.12 cycle
On Tue, Sep 24, 2013 at 10:03:41AM +0300, Andrew W. Nosenko wrote: On Mon, Sep 23, 2013 at 10:58 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: On Mon, Sep 23, 2013 at 3:50 PM, Andy Tai a...@gnu.org wrote: what would this mean for systems not using systemd? Systems not using systemd already fall back to ConsoleKit, which does not have any maintainer. We don't support features like suspend or hibernate on ConsoleKit anymore and it's pretty much on life support only at this point. For 3.12, we will keep the old gnome-session and gdm code that uses ConsoleKit and fork/exec ourselves in the case where you compile without logind support, but I wouldn't expect it to be around much longer. Do you have any specific examples of systems not using systemd that you would like to run GNOME on? Did you heard about FreeBSD? And OpenBSD for that matter. GNOME 3.8 works great: https://www.bsdfrog.org/tmp/gnome.webm -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sun, Aug 11, 2013 at 01:13:40PM +0300, Zeeshan Ali (Khattak) wrote: On Sat, Aug 10, 2013 at 3:09 PM, Robert Roth robert.roth@gmail.com wrote: On Sat, Aug 10, 2013 at 2:42 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth robert.roth@gmail.com wrote: My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, only for the next cycle) are to review the buglist of the module, and extend it to provide library support for various gnome-system-monitor enhancement requests, but in the meantime keep it simple and fast enough to back the upcoming Usage application. Tbh, I think it would be good to start out by reevaluating the rationale for this library. Do we really need it anymore ? What data does g-s-m get from it ? For storage-related data, gio has probably encroached into the territory already. You might be right on that, I will check what GIO can do. For other data, libgtop is mostly a thin wrapper of /proc, iirc. Thas is true for linux systems, but libgtop also supports some BSDs, and other systems, which don't seem to have a procfs Before we take this fact into consideration here, perhaps we should first find out if a modern GNOME system actually work on BSD. We It does. I am actually running a full GNOME 3.8.3 installation on OpenBSD. And part of my job is to deploy such combo on hundreds of machines. -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sun, Aug 11, 2013 at 02:17:29PM +0300, Robert Roth wrote: It does. I am actually running a full GNOME 3.8.3 installation on OpenBSD. And part of my job is to deploy such combo on hundreds of machines. For me this is a pretty good and solid argument for keeping libgtop as an abstraction layer for getting system information, even if we would only have OpenBSD and linux-based systems using GNOME, even if there would be only these two implementations (but there are some more). In fact keeping everything up-to-date, buildable and ported to each system seems like the biggest challenge for me in maintaining libgtop, and would appreciate users of non-linux based OSs using GNOME willing to help sending me a note to know who can test newly ported/help porting new code. You can count on Jasper L.A (jas...@openbsd.org) and myself (ajacou...@openbsd.org) to keep maintaining the OpenBSD backend. -- 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 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: 3.8 feature: Drop or Fix Fallback Mode
On Mon, Oct 22, 2012 at 04:55:50PM +0200, Vincent Untz wrote: Hi, The discussion about features is supposed to heat up next week, but I'll actually be offline. So I'd like to start discussion on the fallback mode today. First of all, go read the wiki page: https://live.gnome.org/ThreePointSeven/Features/DropOrFixFallbackMode It more or less documents the current situation with the fallback mode. And I'm of the opinion that we can't accept this situation for 3.8 anymore. So, the two alternatives I can think of are: a) get more people to work on the fallback mode so that it has a high enough quality and follows the current vision of the project b) do not have a fallback mode anymore (or at least, not the current one...) (if anyone can think of another option, please raise your voice) Please note that option b doesn't necessarily mean that all of the features present in GNOME for the fallback mode get dropped too (this would need to be discussed, and this is possibly up to each maintainer), nor that fallback modules suddenly stop to be maintained (although this might happen if nobody steps up). It's merely about stopping to endorse as offical the current fallback mode. It'd be useful to know to what extent people would be affected if we stop supporting the fallback mode. For instance, last June, Antoine mentioned that llvmpipe support is not there yet on OpenBSD... Hi Vincent. llvmpipe support is now somewhat working on OpenBSD. However it is not yet enabled by default (but will be in the upcoming months, so I wouldn't worry about it). The drawback though is that llvmpipe performance is just not usable for any real work on a workstation. For now, due to the lack of KMS (slowly being worked on), we are stuck with Mesa 7.X. We are looking into merging some stuffs from newer version that could help with the performance but I'm not really hopeful it'll improve that much. That said, technically, it works, I can have gnome-shell running on llvmpipe today. As far as I am concerned and as one of the GNOME packager for OpenBSD, I wouldn't cry if the fallback mode in its current state disappeared... I'd rather have to choose between a fully supported GNOME or no GNOME at all than to rely on a bugy fallback mode. I run it on a couple of places and there are many smallish UI issues which make it look bad. Add to this that some apps now require clutter to work, then i don't see the point in the current fallback mode. So to summarize, I fully agree with your a and b points. -- 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 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 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: fallback mode vs llvmpipe rendering
On Mon, Jun 25, 2012 at 11:05:43AM +0200, Vincent Untz wrote: Hi all, People are contacting me every now and then about gnome-panel. There are several people willing to work on it to improve it, but more with the goal of making a GNOME 2-like session than a fallback session. So far, I've been accepting all contributions, except the ones that make the panel go in another direction than the fallback session. Hi. I know I don't represent the majority nor the core target of GNOME but anyway... :) I for one would like to keep the fallback mode a little longer. I have hundreds of (corporate; these are the only one I can have real stats on) users enjoying GNOME 3 in fallback mode on OpenBSD. I know BSDs aren't of real interest for the GNOME Project but it works amazingly well (on x86, x86-64 and powerpc). We have people working on llvmpipe/gallium/kms support for OpenBSD but it takes time since we are not a large-scale project. That said, I agree about the point that the fallback mode is not really tested anymore by upstream developers for obvious reasons; I currently see several weird issues with it. My point being that if the fallback mode would get better love outside of GNOME then why not. I'm just not a fan of the hard dependency on OpenGL for applications outside of gnome-shell: I also run Linux on the side and even there I have many many issues with 3D drivers; and running Fedora with llvmpipe under VMware, while working, is still very slow. -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fallback mode vs llvmpipe rendering
On Mon, Jun 25, 2012 at 12:08:11PM -0400, Adam Jackson wrote: On Mon, 2012-06-25 at 17:36 +0200, Antoine Jacoutot wrote: We have people working on llvmpipe/gallium/kms support for OpenBSD but it takes time since we are not a large-scale project. llvmpipe has no kernel dependencies (beyond SSE2 support I guess), and I don't intend to change that. I do have a scheme in mind for a slightly I know, it's just part of a common effort in our group, that's why I mentionned kms :) We actually have llvmpipe working; but there is still an issue with cogl that we are trying to figure out. different build of the same code that would require a kernel memory manager, but that would not be done at the expense of the existing Thanks for the info Adam. -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fallback mode vs llvmpipe rendering
On Mon, Jun 25, 2012 at 10:27:13PM +0200, Olav Vitters wrote: For what reason do they use fallback mode? Not being able to run GNOME shell, or not liking GNOME shell? The immediate reason is that they need a coherent Desktop on all their different hardware. And we cannot guarantee hardware 3D rendering will be available for all video chipsets. On OpenBSD with have DRM (1) support for Intel and most of the Radeon cards. Of course we advocate avoiding NVidia and any kind of unsupported hardware but when it's already there... Hence our llvmpipe effort on this platform. I know BSDs aren't of real interest for the GNOME Project but it works amazingly well (on x86, x86-64 and powerpc). We have people working on llvmpipe/gallium/kms support for OpenBSD but it takes time since we are not a large-scale project. llvmpipe is (IMO) something that should only be used because nothing else works. You don't want to rely on llvmpipe by default. Well we kind of do for anything that is not supported by our opensource accelerated drivers. In case hardware rendering is not working nicely, any timeframe when that would change or not? I expect to have the pieces required by gnome-shell and other clutter consumers after GNOME 3.6 is out, so I'd say roughly 4 months. -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, Jan 20, 2012 at 01:57:37PM +0100, Antoine Jacoutot wrote: On Fri, Jan 20, 2012 at 12:37:44PM +, Bastien Nocera wrote: On Fri, 2012-01-20 at 09:34 +0100, Olav Vitters wrote: On Fri, Jan 20, 2012 at 08:04:36AM +, Emmanuele Bassi wrote: On 20 January 2012 03:25, Lennart Poettering mzta...@0pointer.de wrote: Now that gnome-control-center uses systemd's date time mechanism[1], we don't need to ship our own mechanism for that purpose. This also removes the last user of dbus-glib in gnome-settings-daemon [2]. Are there plans to provide a systemd-compatible backend for those systems that cannot run systemd? IIRC ubuntu did some work there: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit I guess the question from Ryan was more like: what happens on systems without an implementation of that D-Bus API which systemd provides? I guess we need to review, expand and announce the following again: https://live.gnome.org/PortabilityMatrix I don't know who filled in the line for the date time mechanism, but there was never any OpenBSD support in the old mechanism. True. I can confirm that (although work was ongoing). Meh, I forgot to mention that settings the time/Region/City... worked fine. Only NTP wasn't supported. -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
