Re: Anyone going to be using ConsoleKit for 3.16 ?
It might be nice to put together a wiki page with pointers to the various patches that are needed for CK support in 3.16 ___ 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 Wed, 2015-02-04 at 10:24 +0100, Olav Vitters wrote: On Tue, Feb 03, 2015 at 03:36:36PM -0500, Ray Strode wrote: Hi, On Tue, Feb 3, 2015 at 12:00 PM, Olav Vitters o...@vitters.nl wrote: Can't we hide it behind a --this-is-going-away-in-3.18 configure switch? That was certainly a possibility, but, what's the advantage of doing it? The bug Antoine pointed to shows that distros that use ConsoleKit in 3.14 are already shipping patches to keep it working. No one who has chimed in has said that one more would be a big deal. And this is really only for one release, by 3.18 everyone should be using the newer apis, and then the patches will go away. It wouldn't be a big deal to deprecate for a release but no one who will be using ConsoleKit in 3.16 advocated for that. And cutting out the code is a net win for the codebase, so I'd rather do it now than later. Because I'm wondering if we're reaching everyone with this announcement, and it is a bit late in the cycle. Having a configure option would not mean it is suddenly gone (if they miss this email, they'd also not know about the patch), but it clearly tells them it'll be gone. 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. ___ 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 Tue, Feb 03, 2015 at 03:36:36PM -0500, Ray Strode wrote: Hi, On Tue, Feb 3, 2015 at 12:00 PM, Olav Vitters o...@vitters.nl wrote: Can't we hide it behind a --this-is-going-away-in-3.18 configure switch? That was certainly a possibility, but, what's the advantage of doing it? The bug Antoine pointed to shows that distros that use ConsoleKit in 3.14 are already shipping patches to keep it working. No one who has chimed in has said that one more would be a big deal. And this is really only for one release, by 3.18 everyone should be using the newer apis, and then the patches will go away. It wouldn't be a big deal to deprecate for a release but no one who will be using ConsoleKit in 3.16 advocated for that. And cutting out the code is a net win for the codebase, so I'd rather do it now than later. Because I'm wondering if we're reaching everyone with this announcement, and it is a bit late in the cycle. Having a configure option would not mean it is suddenly gone (if they miss this email, they'd also not know about the patch), but it clearly tells them it'll be gone. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Killing the Severity field value trivial in Bugzilla
tl;dr Might happen soon. While/after upgrading to Bugzilla 4.4 soon(TM) [1], I would like to get rid of Bugzilla's trivial Severity field value in order to get a slightly shorter list of confusing choices. That means it will not be possible anymore to set that Severity value on a bug report, and I would bump the Severity value //only for those 492 open reports// from trivial to minor (while ignoring closed ones). IMHO, trivial should be expressed by setting the gnome-love keyword. Plus trivial is simply not a severity: A critical crasher bug can be trivial to fix when it's just a typo in a function call. And so this might just happen if noone speaks up to protest. andre (PS: Bikesheds about severity vs priority vs importance vs complexity go to your new separate thread. I prefer my stuff to be actionable chunks.) [1] https://mail.gnome.org/archives/desktop-devel-list/2015-January/msg00066.html -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Installing DBus interface files for services
On Tue, 03.02.15 18:29, Cosimo Cecchi (cosi...@gnome.org) wrote: On Mon, Feb 2, 2015 at 3:22 AM, Lennart Poettering mzta...@0pointer.de wrote: Oh no, that's not what I meant. I was more proposing to pull them once, while you develop your stuff, and then shipping them in your own tarball. So, don't pull them dynamically when you start building, but you keep your own copy of the XML bits of other APIs, frozen and stable in time in your own project. That's what some modules are doing today already, but I don't think it really addresses my use case. I would like to be able to easily build client code that interacts with a DBus service on the system without manually hunting for that interface from the service's git repository, ideally with a nice autotool integration like Philip proposed at the beginning of this thread. Well, don't hunt it down from some git repo, just pull it ouf some running daemon you are testing against. So it seems that if we were to do that we're saying: - services should install one of those files for each interface - such files should have the same name as the interface and not contain other nodes Well, are you sure the gdbus tools can even read introspection files right now that do not start with node but with interface? - tooling would verify that the above two are true? - it wouldn't be a great idea to use this for clients that ends up exposing the generated code through a public API Lennart, you also mentioned about cross-build problems, but I'm not really sure what those would be with this proposal - could you expand on that? Well, in sd-bus you define your bus interfaces in a C struct, with some syntactic sugar made of macros. The XML stuff is something you never see, it's generated at runtime from these structs. If you wanted to store the XML stuff on disk you'd thus have to run the program, and oull it out from there. But people who cross-build generally don't like it if they have to run the stuff they just built to complete the build process, because that usually requires the build and the target arch to be the same... Also note that sd-bus' XML introspection data is very reduced, it contains no parameter names or anything. In sd-bus we actually try to hide the fact that XML is used for this as much as we can, developers don't come into contact with it if at all possible... I figure it all boils down to the difference in philosophy: in gdbus the XML introspection data is the source of evertyhing and the C code built from that. In sd-bus the C code is the source of everything and the XML introspection data generated from that. Lennart -- Lennart Poettering, Red Hat ___ 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, On Wed, Feb 4, 2015 at 4:24 AM, Olav Vitters o...@vitters.nl wrote: Having a configure option would not mean it is suddenly gone (if they miss this email, they'd also not know about the patch), but it clearly tells them it'll be gone. Okay so there's a pretty good middle ground we can come up with here. I'll leave the --with-console-kit argument in configure, but if it gets used, then I'll error out and point to the wiki page mclasen suggests in another message. --Ray ___ 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 Wed, Feb 04, 2015 at 09:48:19AM -0500, Ray Strode wrote: On Wed, Feb 4, 2015 at 4:24 AM, Olav Vitters o...@vitters.nl wrote: Having a configure option would not mean it is suddenly gone (if they miss this email, they'd also not know about the patch), but it clearly tells them it'll be gone. Okay so there's a pretty good middle ground we can come up with here. I'll leave the --with-console-kit argument in configure, but if it gets used, then I'll error out and point to the wiki page mclasen suggests in another message. Ah, that's awesome! -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
