Re: multiple vala versions in 3.4
On Fri, Jan 20, 2012 at 2:30 PM, Matthias Clasen wrote: >> On 01/19/2012 10:32 PM, Colin Walters wrote: >>> >>> But others (folks at least) fail to compile with 0.15. >> >> >> This question might seem a little naive, but could someone highlight me why >> the vala compiler can't stay backward compatible from release to release? > > Indeed. Until vala grows up a little more, its increasing use in the > desktop is a growing problem. Being a maintainer of 2 vala projects in GNOME, I can tell you that valac itself is pretty stable these days and it gets more and more stable all the time. The issue is the bindings usually. There are way too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Sat, 2012-01-21 at 01:07 +0100, Lennart Poettering wrote: > On Fri, 20.01.12 17:08, Ted Gould (t...@gould.cx) wrote: > > > I already maintain a ton of stuff, and I try to keep maintenance burden > > > and bureaucracy small for myself. Hence the Wiki, and not a complex > > > standards process and a git repo. All API versioning we need should be > > > done within the D-Bus interface itself (where the right place is for it > > > anyway) and all documentation versioning by using the history > > > functionality of the wiki. > > > > I guess that I don't see that as adequate (hence why I suggested > > something more formal). > > What could be more formal than a machine readable interface definition > as it is included in the Wiki page? I was more referring to formality of process rather than how the interface is specified. I imagine there won't be many versions of the interfaces, but there will be of the tools (like systemd) that implement them. > > One way that I had thought this could work on the Debian packaging > > side of things would be using the Requires/Provides labels in the > > package. So then something like systemd could provide > > "freedesktop-system-interfaces-45" and GNOME could require that. > > Right. What could be a better identifier for an interface and its > version, than, well, the interface name which includes the version? > i.e. use "org.freedesktop.timedate1" for that. And if you don't like the > dots, then replace them by dashes or so, for use by your package > manager. > > > There could also be other providers and users who wanted to switch > > would then get their choice. Pulling the version number from the wiki > > for all the different interfaces would make that complex and > > burdensome to maintain for the packagers involved. Which is why I > > suggested something with a more stable and uniform release process. > > I am not sure how better to achieve uniformity and stability than by > by using the version information that is embedded in the interface > definition itself? > > I am sorry, but you explicitly *don't* want another level of naming or > versioning here, because then you'd have to maintain multiple versioning > streams for the same stuff, and that'd suck. So, let's use a simple use case. For what ever reason, it is decided that one of the interfaces needs a new property. I'm guessing that you'd expect that the interface name wouldn't change as it would be backwards compatible. Now GNOME Control Center comes along and needs that new property to implement their interface. How should G-C-C express that requirement? --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 17:08, Ted Gould (t...@gould.cx) wrote: > > I already maintain a ton of stuff, and I try to keep maintenance burden > > and bureaucracy small for myself. Hence the Wiki, and not a complex > > standards process and a git repo. All API versioning we need should be > > done within the D-Bus interface itself (where the right place is for it > > anyway) and all documentation versioning by using the history > > functionality of the wiki. > > I guess that I don't see that as adequate (hence why I suggested > something more formal). What could be more formal than a machine readable interface definition as it is included in the Wiki page? > One way that I had thought this could work on the Debian packaging > side of things would be using the Requires/Provides labels in the > package. So then something like systemd could provide > "freedesktop-system-interfaces-45" and GNOME could require that. Right. What could be a better identifier for an interface and its version, than, well, the interface name which includes the version? i.e. use "org.freedesktop.timedate1" for that. And if you don't like the dots, then replace them by dashes or so, for use by your package manager. > There could also be other providers and users who wanted to switch > would then get their choice. Pulling the version number from the wiki > for all the different interfaces would make that complex and > burdensome to maintain for the packagers involved. Which is why I > suggested something with a more stable and uniform release process. I am not sure how better to achieve uniformity and stability than by by using the version information that is embedded in the interface definition itself? I am sorry, but you explicitly *don't* want another level of naming or versioning here, because then you'd have to maintain multiple versioning streams for the same stuff, and that'd suck. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 23:48 +0100, Lennart Poettering wrote: > On Fri, 20.01.12 16:29, Ted Gould (t...@gould.cx) wrote: > > On Fri, 2012-01-20 at 23:20 +0100, Lennart Poettering wrote: > > > On Fri, 20.01.12 08:59, Ted Gould (t...@gould.cx) wrote: > > > > It seems to me that this would be a good usage of Freedesktop. I'd be > > > > happy to maintain such a repository if people would be willing to use > > > > it. > > > > > > Yeah, it's a great use of fdo, and that's why I put it on fdo. > > > > Just to be clear, you'd be happy if the interfaces were moved to a > > different repository that was versioned independently of systemd? And > > then systemd could depend on a particular release of those interfaces. > > Honestly, I don't see why. The wiki is just fine. The interfaces are > versioned independently of systemd (that's why their interface names and > object paths contain version numbers (currently at "1"). And those > version numbers are specific to the API, and entirely unrelated to > systemd. It's basically how D-Bus versioning is generally accepted to > work). > > I already maintain a ton of stuff, and I try to keep maintenance burden > and bureaucracy small for myself. Hence the Wiki, and not a complex > standards process and a git repo. All API versioning we need should be > done within the D-Bus interface itself (where the right place is for it > anyway) and all documentation versioning by using the history > functionality of the wiki. I guess that I don't see that as adequate (hence why I suggested something more formal). One way that I had thought this could work on the Debian packaging side of things would be using the Requires/Provides labels in the package. So then something like systemd could provide "freedesktop-system-interfaces-45" and GNOME could require that. There could also be other providers and users who wanted to switch would then get their choice. Pulling the version number from the wiki for all the different interfaces would make that complex and burdensome to maintain for the packagers involved. Which is why I suggested something with a more stable and uniform release process. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 16:29, Ted Gould (t...@gould.cx) wrote: > On Fri, 2012-01-20 at 23:20 +0100, Lennart Poettering wrote: > > On Fri, 20.01.12 08:59, Ted Gould (t...@gould.cx) wrote: > > > It seems to me that this would be a good usage of Freedesktop. I'd be > > > happy to maintain such a repository if people would be willing to use > > > it. > > > > Yeah, it's a great use of fdo, and that's why I put it on fdo. > > Just to be clear, you'd be happy if the interfaces were moved to a > different repository that was versioned independently of systemd? And > then systemd could depend on a particular release of those interfaces. Honestly, I don't see why. The wiki is just fine. The interfaces are versioned independently of systemd (that's why their interface names and object paths contain version numbers (currently at "1"). And those version numbers are specific to the API, and entirely unrelated to systemd. It's basically how D-Bus versioning is generally accepted to work). I already maintain a ton of stuff, and I try to keep maintenance burden and bureaucracy small for myself. Hence the Wiki, and not a complex standards process and a git repo. All API versioning we need should be done within the D-Bus interface itself (where the right place is for it anyway) and all documentation versioning by using the history functionality of the wiki. > So then, for instance, GNOME could say it depends on release 45 of the > interfaces and a particular version of systemd could implement that > version of the interfaces. It should just say it depends on the D-Bus interface org.freedesktop.hostname1, and that should be sufficiently exact, and is easily readable from the GNOME sources... > If you're happy with that, I'm happy, let's set up a repo. Thanks, but no thanks. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 23:20 +0100, Lennart Poettering wrote: > On Fri, 20.01.12 08:59, Ted Gould (t...@gould.cx) wrote: > > It seems to me that this would be a good usage of Freedesktop. I'd be > > happy to maintain such a repository if people would be willing to use > > it. > > Yeah, it's a great use of fdo, and that's why I put it on fdo. Just to be clear, you'd be happy if the interfaces were moved to a different repository that was versioned independently of systemd? And then systemd could depend on a particular release of those interfaces. So then, for instance, GNOME could say it depends on release 45 of the interfaces and a particular version of systemd could implement that version of the interfaces. If you're happy with that, I'm happy, let's set up a repo. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 15:25, Bastien Nocera (had...@hadess.net) wrote: > > Then we need to clearly communicate what we expect distributors to > > provide. What systemd interfaces are we allowed to depend on without > > asking? > > The systemd interfaces that don't rely on systemd being the init system. > In this case, hostnamed, localed and timedated. > > I'm sure we'll get to have discussions again when ConsoleKit goes away. > For now, the multi-seat support code in systemd is a compile-time option > for gnome-control-center, and soon for gnome-settings-daemon. gdm's coming multi-seat support is a compile and runtime option. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 09:39, Ted Gould (t...@gould.cx) wrote: > On Fri, 2012-01-20 at 10:22 -0500, Ryan Lortie wrote: > > On Fri, 2012-01-20 at 08:59 -0600, Ted Gould wrote: > > > I think that this would be more apparent if the DBus interface > > > descriptions were maintained outside of the systemd codebase. > > > >http://www.freedesktop.org/wiki/Software/systemd/timedated > > > > I won't comment on if you accept this as being sufficiently divorced > > from systemd or not... > > From the wiki page: > > systemd 30 and newer include systemd-timedated > > I would conclude that any dependency on that interface is a dependency > on systemd version 30 or newer. Therefore, GNOME has that as a > dependency in 3.4 on systemd > 30. > > To be clear, I don't think that's a problem in how the page is written, > I think that's a reality of where the interface is defined. Hmm, cool. If it's from the systemd project it must be evil? I totally see that, thank you. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 08:59, Ted Gould (t...@gould.cx) wrote: > On Fri, 2012-01-20 at 12:37 +, Emmanuele Bassi wrote: > > the dependency is not on systemd - it's on a DBus API. systemd provides > > one implementation of that DBus API. > > I think that this would be more apparent if the DBus interface > descriptions were maintained outside of the systemd codebase. Yes, and they are. http://www.freedesktop.org/wiki/Software/systemd/timedated http://www.freedesktop.org/wiki/Software/systemd/hostnamed http://www.freedesktop.org/wiki/Software/systemd/localed That's the problem with you people: one tries to be nice to you, and document it all in much detail outside of the codebase, keep the systemd name out of all the interfaces, to make it really easy for you guys to adopt this without having to touch this evil systemd stuff at all, but you don't appreciate it, you just complain anyway that we'd mistreat you and everything was just an evil plot against you. You guys were in the loop, you guys even wrote alternate implementation of this stuff already, you guys discussed it in detail at the last UDS. And I was very nice to you by keeping the systemd name out of it and documenting it on fdo, and Bastien even showed you how easy it is two build the relevant systemd components without having to adopt systemd all the way. So you have multiple ways out of your perceived problem! So, what more do you want? There's nothing to complain about. Instead, I'd very much appreciate a "thank you" though. > It seems to me that this would be a good usage of Freedesktop. I'd be > happy to maintain such a repository if people would be willing to use > it. Yeah, it's a great use of fdo, and that's why I put it on fdo. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 15:06, Sebastien Bacher (seb...@ubuntu.com) wrote: > > Le 20/01/2012 13:00, Olav Vitters a écrit : > >It is called systemd, and it is NOT a dependency. What we depend on is > >a few simple dbus APIs. If an OS doesn't implement those APIs, certain > >functionality won't work. These APIs have been implemented in systemd, > >but they can (and are being) implemented elsewhere. > > > >What I've said above is nothing new btw (to me). It has been discussed > >openly, think on this mailing list. > > > >What I am suggesting now is that we clearly document this (depend on the > >API being implemented). > Hi, > > Ok, so as a distributor of GNOME I think that what we (Ubuntu) would > like to see: > - some public list of what services GNOME rely on to be fully working > - some public announce earlier in the cycle, or if possible one > cycle in advance of what API will need to be provided for the next > GNOME release to be fully working > - some details (spec?) about the API used for those who want to > implement compatible ones > > It's fine to be using new services but if GNOME wants distributors > to provide a good GNOME experience system requirements should be > announced in advances with a clear description of the protocol to > give enough time to integrators to work on providing those services. You know, your complaining would be a bit more believable if Google wouldn't find this for us: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit So, the problem set has been known for a while, a number of Canonical desktop team members have been subscribed to that page, the documentation for the interfaces is all available, some code has already been written by Canonical. So I really don't see what went wrong here, except maybe that Canonical's internal communication didn't work out so well? Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 21:50, Steve Frécinaux (nudr...@gmail.com) wrote: > > On 01/20/2012 06:33 PM, Nirbheek Chauhan wrote: > >Try to think of it as a freedesktop standard for time and date (like > >org.fdo.Notifications). It even uses the same DBus namespace! Once a > >provider is implemented (by porting timedated or whatever) it can be > >reused everywhere. > > It might be wise to just make it a plain, documented, dbus spec. Thank god I am so wise: http://www.freedesktop.org/wiki/Software/systemd/timedated Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 10:29, Ryan Lortie (de...@desrt.ca) wrote: > As mentioned above -- Lennart has no intention of making it easy to use > his code outside of systemd (and I don't blame him). This is not a > matter of some simple packaging -- more like reimplementing a D-Bus > interface in a new code base (which could originally be copied out of > systemd, but then would have to be maintained separately). This is not > an afternoon's work. Given that Ubuntu already has code for these mechanisms, and a lots of DONEs on https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit I'd assume that their code is already quite far ahead. It's targeted for their 12.04 release, which I think is the current one that is developed... Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 08:47, Ryan Lortie (de...@desrt.ca) wrote: > > hi Bastien, > > On Fri, 2012-01-20 at 12:36 +, Bastien Nocera wrote: > > No, the distributions/systems that choose not to use systemd will have > > to provide a compatible D-Bus service. > > This is what I guessed you'd say. > > > It can be something "extracted" from systemd, or something new and > > revived from the old date and time mechanism, but it won't be something > > we support and maintain in gnome-settings-daemon. > > > And I'm glad I have 3000 less lines code to maintain. > > I'm just a little bit concerned about how this looks. I love when we > can delete code, but we're doing it by disabling a previously-working > feature for a portion of our users. > > If we introduced new optional features that depended on a particular > systemd functionality in order to operate, it would be one thing. We do > that often. This change is a regression of existing functionality in > the name of "I don't feel like maintaining it anymore". > > I'd also feel a bit better if I thought you had made efforts to get in > touch with those that would be affected by this regression. Ubuntu > isn't shipping GNOME 3.4 g-s-d/g-c-c, this cycle, for example, but for > the last week I've been trying to convince them that they should. If I > had succeeded (which I am now glad I didn't) then this change would have > been a royal pain, creating a whole lot of new work to fit into an > already full schedule. > > Many of our own end-users will still want to install GNOME 3.4 onto > their Ubuntu systems (myself included). I look forward to the mention > in our release notes about how they can no longer change their time > because we wanted to delete a bit of code. Note that The Ubuntu folks have been well aware of all of this coming. How I know that? Because at their last UDS they scheduled a session about rewriting those mechanisms for Ubuntu, and they even have a project page up on launchpad: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On 01/20/2012 06:33 PM, Nirbheek Chauhan wrote: Try to think of it as a freedesktop standard for time and date (like org.fdo.Notifications). It even uses the same DBus namespace! Once a provider is implemented (by porting timedated or whatever) it can be reused everywhere. It might be wise to just make it a plain, documented, dbus spec. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On 20 Jan 2012, at 17:21, Sebastien Bacher wrote: > Le 20/01/2012 17:50, Bastien Nocera a écrit : >> In about 40 minutes, I created a binary RPM[1] that contains the 3 >> services we care about in GNOME from the systemd Fedora package. I >> believe you do something similar. > Thanks, that works but is not really optiomal (i.e that could easily lead to > a non well maintained,half broken systemd in Ubuntu because it has been > packaged by people who care only about the services and not about the other > features from systemd). > > But anyway from a distributor perspective this specific problem is orthogonal > to the discussion: > - the issue is not Debian,Ubuntu specific They're the only ones really complaining though... The others took it upon themselves to do the integration work. Only Fedora, Debian/Ubuntu and SUSE were supported. SUSE haven't complained either. > - the issue is not that distributors have work to do to integrate GNOME > - nobody asked you to solve integration issues for downstreams > > What as a downstream we would like is early communication from the project on > what platform requirements will be added so we have time to do our work and > deliver a good GNOME experience to our GNOME users. You're missing the fact that you (personally) received emails about that feature by virtue of being subscribed to gnome-control-center bugs. Consider this a, if rather late, notice that we'll use the systemd timedated API in GNOME 3.4. I believe enough work-arounds have been given for the downstreams for which it's a problem. But at the end of the day, planning is pretty complicated when I'm the only person reviewing project-wide patches in g-c-c. So you get the notice at the same time as others, myself included: when I merge the patch. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, Jan 20, 2012 at 10:49 PM, Emmanuele Bassi wrote: > On 20 January 2012 17:12, Michael Biebl wrote: >> It's unfortunately not as simple as that as far as Debian is concerned >> or any other non-Linux distro. systemd is Linux-only. The >> aforementioned components timedated, hostnamed and localed can't be >> compiled on non-Linux systems. > > this hasn't changed: non-Linux systems were not supported before > either. actually using, by a neutral DBus interface instead of ad hoc > code for each platform, it may be easier to get support on other > platforms without requiring to patch g-c-c directly. > For those finding it hard to understand how this is better than before: Try to think of it as a freedesktop standard for time and date (like org.fdo.Notifications). It even uses the same DBus namespace! Once a provider is implemented (by porting timedated or whatever) it can be reused everywhere. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le 20/01/2012 17:50, Bastien Nocera a écrit : In about 40 minutes, I created a binary RPM[1] that contains the 3 services we care about in GNOME from the systemd Fedora package. I believe you do something similar. Thanks, that works but is not really optiomal (i.e that could easily lead to a non well maintained,half broken systemd in Ubuntu because it has been packaged by people who care only about the services and not about the other features from systemd). But anyway from a distributor perspective this specific problem is orthogonal to the discussion: - the issue is not Debian,Ubuntu specific - the issue is not that distributors have work to do to integrate GNOME - nobody asked you to solve integration issues for downstreams What as a downstream we would like is early communication from the project on what platform requirements will be added so we have time to do our work and deliver a good GNOME experience to our GNOME users. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
hi; On 20 January 2012 17:12, Michael Biebl wrote: > It's unfortunately not as simple as that as far as Debian is concerned > or any other non-Linux distro. systemd is Linux-only. The > aforementioned components timedated, hostnamed and localed can't be > compiled on non-Linux systems. this hasn't changed: non-Linux systems were not supported before either. actually using, by a neutral DBus interface instead of ad hoc code for each platform, it may be easier to get support on other platforms without requiring to patch g-c-c directly. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, Jan 20, 2012 at 04:00:47PM +0100, Sebastien Bacher wrote: > The current way of doing things just seem far to be professional, > GNOME can probably do much better on communicating their requirement > and documenting them. I said that as well in the bit you didn't quote + in other emails. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Am 20. Januar 2012 17:50 schrieb Bastien Nocera : > On Fri, 2012-01-20 at 10:29 -0500, Ryan Lortie wrote: > >> > and get them to package up the missing >> > bits. An afternoon's work, and no need to scream bloody murder. >> >> As mentioned above -- Lennart has no intention of making it easy to use >> his code outside of systemd (and I don't blame him). This is not a >> matter of some simple packaging -- more like reimplementing a D-Bus >> interface in a new code base (which could originally be copied out of >> systemd, but then would have to be maintained separately). This is not >> an afternoon's work. > > In about 40 minutes, I created a binary RPM[1] that contains the 3 > services we care about in GNOME from the systemd Fedora package. I > believe you do something similar. It's unfortunately not as simple as that as far as Debian is concerned or any other non-Linux distro. systemd is Linux-only. The aforementioned components timedated, hostnamed and localed can't be compiled on non-Linux systems. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 10:29 -0500, Ryan Lortie wrote: > > and get them to package up the missing > > bits. An afternoon's work, and no need to scream bloody murder. > > As mentioned above -- Lennart has no intention of making it easy to use > his code outside of systemd (and I don't blame him). This is not a > matter of some simple packaging -- more like reimplementing a D-Bus > interface in a new code base (which could originally be copied out of > systemd, but then would have to be maintained separately). This is not > an afternoon's work. In about 40 minutes, I created a binary RPM[1] that contains the 3 services we care about in GNOME from the systemd Fedora package. I believe you do something similar. 1) Try to make it compile on your distribution. I needed that patch: https://gist.github.com/1648337 That's the hardest part if your distribution isn't one listed here: http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac#n411 Make sure to disable everything you don't need, for example: https://gist.github.com/1648324#L57 2) Remove all the unnecessary files from the installed package: https://gist.github.com/1648324#L81 3) Make the D-Bus service work with D-Bus instead of systemd: https://gist.github.com/1648324#L99 Voila. You have something that kind of works. Patches for Debian/Ubuntu specific support can go upstream. Cheers [1]: That would be because it's been so long I was a Debian Developer, they revoked my account. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le 20/01/2012 17:28, Matthias Clasen a écrit : How about: distributors should keep on top of what's happening with the things they are distributing ? Right, that's one possibility (and basically what it's happening nowadays), but it makes the distributors' job harder and so increases the likeness that GNOME users will get a suboptimal experience on their distribution. It's neither a win situation for GNOME since it's not showing as good as it should for those users nor for the distributors. Or maybe you just don't have time for that because you are busy working on your own platform ? Dunno for others but speaking for Ubuntu as a distribution we do keep with what is happening. This cycle we decided to stay on GNOME 3.2 so we are fine and we will have time to add the services required before landing 3.4 next cycle. Jeremy and some others are working to provide GNOME 3.4 in a ppa for the users who want it though, that will like create issues for them and for the users who will run the next version and will get a degraded experience. It's also going to be an issue for i.e Debian. They seemed to be looking at GNOME 3.4 for the next release (their freeze is a bit after 3.4) but they will not use systemd by default so they either have to figure what they can do with their limited resources, ship with non working features, or stay on 3.2. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, Jan 20, 2012 at 10:09 AM, Sebastien Bacher wrote: > Le 20/01/2012 15:49, Bastien Nocera a écrit : > > > This wiki page is something but it would be better if GNOME could: > - do public announces a cycle in advance of what new system requirements > will be added to let distributors adapt to those > - document somewhere what interfaces exactly are required and since when > There's a lot of gnome-should-do-this and gnome-should-do-that in this thread. How about: distributors should keep on top of what's happening with the things they are distributing ? Or maybe you just don't have time for that because you are busy working on your own platform ? Anyway, I agree that we should keep the portability matrix updated, I'll give it a look today. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 09:51 -0500, Colin Walters wrote: > On Fri, 2012-01-20 at 14:48 +, Maciej Marcin Piechotka wrote: > > On Fri, 2012-01-20 at 09:45 -0500, Colin Walters wrote: > > > On Fri, 2012-01-20 at 12:24 +, Maciej Marcin Piechotka wrote: > > > > > > > The 0.6 branch is the stable one while 0.7 have not stabilised API/ABI > > > > (with expected breaks). I would advice to either follow 0.6 series or > > > > 0.6 branch (not master) until 0.7 will get stable API. > > > > > > Ah, ok - that's what I need to know. So we should definitely be > > > sticking with 0.6 for GNOME 3.4. And it looks like you have a 0.6 > > > branch which is good - I want to track git, not a tarball snapshot. > > > > > > > Yes. 0.6 is still maintained. There should be a bugfix release during > > this weekend (I need just an advice from gir specialist about > > shared-library attribute of .typelib. Whom should I contact?) > > You're talking to him now =) What's the question? > Could you comment what would be proper short-time fix on https://bugzilla.gnome.org/show_bug.cgi?id=667529 > > also > > allowing building against vala master. > > How about this patch (I am a Vala noob, but I want to try to pitch in > here rather than talk endlessly) > I'm currently working on making 0.7 branch work (it compiles but fails tests). If backporting existing patch will fail I will use yours + conditional compilation. PS. I'm not a vala wizard either. > There are a *ton* of compiler warnings but it builds, ship it etc... I'm trying to slowly get rid of them. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 10:22 -0500, Ryan Lortie wrote: > On Fri, 2012-01-20 at 08:59 -0600, Ted Gould wrote: > > I think that this would be more apparent if the DBus interface > > descriptions were maintained outside of the systemd codebase. > >http://www.freedesktop.org/wiki/Software/systemd/timedated > > I won't comment on if you accept this as being sufficiently divorced > from systemd or not... From the wiki page: systemd 30 and newer include systemd-timedated I would conclude that any dependency on that interface is a dependency on systemd version 30 or newer. Therefore, GNOME has that as a dependency in 3.4 on systemd > 30. To be clear, I don't think that's a problem in how the page is written, I think that's a reality of where the interface is defined. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 14:30 +, Bastien Nocera wrote:
> This particular change was mentioned nearly a year ago on this very same
> list. It's not my fault Ubuntu (in this particular case) didn't take the
> hint to start packaging the relevant D-Bus services, or rewriting them
> to fit their use.
If you are referring to the discussion that happened last May, I would
consider it a "mention", certainly... but nothing like any sort of a
notification. You said that you wouldn't mind making use of the
interfaces, but would prefer if Lennart could make more efforts to split
them out so they could be used on other platforms. Lennart replied that
he would do no such thing, and as far as I know, that was the end of the
conversation.
This doesn't fit my idea of effective communication of intent.
> You're making a fuss because you ("Ubuntu")
Are you attempting to annoy me...
> Stop this us vs. them thing
...or just set up for a double-take?
> and get them to package up the missing
> bits. An afternoon's work, and no need to scream bloody murder.
As mentioned above -- Lennart has no intention of making it easy to use
his code outside of systemd (and I don't blame him). This is not a
matter of some simple packaging -- more like reimplementing a D-Bus
interface in a new code base (which could originally be copied out of
systemd, but then would have to be maintained separately). This is not
an afternoon's work.
Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 10:12 -0500, Shaun McCance wrote: > On Fri, 2012-01-20 at 12:36 +, Bastien Nocera wrote: > > On Thu, 2012-01-19 at 17:49 -0500, Ryan Lortie wrote: > > > hi Bastien, > > > > > > On Thu, 2012-01-19 at 22:38 +, Bastien Nocera wrote: > > > > commit 27fa171efe4179c0a42ec79e0dc501077f042a08 > > > > Author: Bastien Nocera > > > > Date: Thu Jan 19 22:33:21 2012 + > > > > > > > > datetime: Remove datetime D-Bus mechanism > > > > > > > > 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? > > > > No, the distributions/systems that choose not to use systemd will have > > to provide a compatible D-Bus service. > > > > It can be something "extracted" from systemd, or something new and > > revived from the old date and time mechanism, but it won't be something > > we support and maintain in gnome-settings-daemon. > > Then we need to clearly communicate what we expect distributors to > provide. What systemd interfaces are we allowed to depend on without > asking? The systemd interfaces that don't rely on systemd being the init system. In this case, hostnamed, localed and timedated. I'm sure we'll get to have discussions again when ConsoleKit goes away. For now, the multi-seat support code in systemd is a compile-time option for gnome-control-center, and soon for gnome-settings-daemon. > Any of them? I'm not going to read that old 116-post thread > on d-d-l to find out. > > We used to provide pages like this for every release: > > http://live.gnome.org/TwoPointNinetyone/ExternalDependencies > > Now, not so much. This should have been updated: https://live.gnome.org/PortabilityMatrix ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 08:59 -0600, Ted Gould wrote: > I think that this would be more apparent if the DBus interface > descriptions were maintained outside of the systemd codebase. http://www.freedesktop.org/wiki/Software/systemd/timedated I won't comment on if you accept this as being sufficiently divorced from systemd or not... Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 12:36 +, Bastien Nocera wrote: > On Thu, 2012-01-19 at 17:49 -0500, Ryan Lortie wrote: > > hi Bastien, > > > > On Thu, 2012-01-19 at 22:38 +, Bastien Nocera wrote: > > > commit 27fa171efe4179c0a42ec79e0dc501077f042a08 > > > Author: Bastien Nocera > > > Date: Thu Jan 19 22:33:21 2012 + > > > > > > datetime: Remove datetime D-Bus mechanism > > > > > > 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? > > No, the distributions/systems that choose not to use systemd will have > to provide a compatible D-Bus service. > > It can be something "extracted" from systemd, or something new and > revived from the old date and time mechanism, but it won't be something > we support and maintain in gnome-settings-daemon. Then we need to clearly communicate what we expect distributors to provide. What systemd interfaces are we allowed to depend on without asking? Any of them? I'm not going to read that old 116-post thread on d-d-l to find out. We used to provide pages like this for every release: http://live.gnome.org/TwoPointNinetyone/ExternalDependencies Now, not so much. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le 20/01/2012 15:49, Bastien Nocera a écrit : Most of them are listed in the page that Olav pointed to: https://live.gnome.org/PortabilityMatrix Not updating it for the latest changes is my mistake. This wiki page is something but it would be better if GNOME could: - do public announces a cycle in advance of what new system requirements will be added to let distributors adapt to those - document somewhere what interfaces exactly are required and since when The actual talk of using systemd's timedated and localed services was in May 2011: http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00429.html And the bugzilla itself (for which you receive notification mails) opened since September. I think that's enough time to implement the functionality. Right, out of the fact that there were different opinions in the community on those topic and no consensus in that discussion, nor project statement that those new requirements had been approved and would be enforced. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 12:37 +, Emmanuele Bassi wrote: > the dependency is not on systemd - it's on a DBus API. systemd provides > one implementation of that DBus API. I think that this would be more apparent if the DBus interface descriptions were maintained outside of the systemd codebase. If they're maintained inside the systemd codebase, for all practical purposes you're depending on a particular version of systemd to provide the version of the interfaces you support. They will change, if the only way to express this change is through a systemd version number, you're depending on systemd. It seems to me that this would be a good usage of Freedesktop. I'd be happy to maintain such a repository if people would be willing to use it. --Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 09:48 -0500, Jeremy Bicha wrote: > While writing the extra code that Debian and Ubuntu will need may only > take a day or a few days' work for you, it's probably beyond my > abilities. I don't think it is. Take systemd's tarball, and call it systemd-services. Package up systemd's D-Bus services, without the rest of the init system. Then you can test and better your Debian specific patches for those services. > Dropping support for Debian & Ubuntu doesn't seem a very friendly > move, and it's only going to delay getting GNOME 3.4 into the hands of > your user base. We're not dropping support. We're expecting the distributions to ship their own config files modifying D-Bus services. You can use systemd, or not, that's irrelevant. The point is that we shouldn't have a "if (fedora) else if (debian) else if (suse) else if..." in GNOME code. This does that. And if you _really_ wanted to ship GNOME 3.4 in Ubuntu without packaging up systemd's D-Bus services, you can also revert the 2 patches. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le 20/01/2012 15:47, Olav Vitters a écrit : FWIW and IMO, this is a packaging issue. If you want to provide GNOME 3.4, you'll need to ensure you have the right functionality in your OS/distribution. Well, GNOME should start by communicating what are the "right functionality" and doing it one cycle is advance would be nice, you can't assume that all your distributors track every git commit and will be able to accomodate new requirements added some weeks before feature freeze. Could you also point to a GNOME documentations telling what methods on this dbus service the system should implement for GNOME to be working correctly? The current way of doing things just seem far to be professional, GNOME can probably do much better on communicating their requirement and documenting them. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, Jan 20, 2012 at 08:47:28AM -0500, Ryan Lortie wrote: > Many of our own end-users will still want to install GNOME 3.4 onto > their Ubuntu systems (myself included). I look forward to the mention > in our release notes about how they can no longer change their time > because we wanted to delete a bit of code. FWIW and IMO, this is a packaging issue. If you want to provide GNOME 3.4, you'll need to ensure you have the right functionality in your OS/distribution. I'm not sure in above quote when you refer to GNOME or when to Ubuntu. However, I don't see the relevance of mentioning Ubuntu in the GNOME 3.4 release notes. If you want to provide GNOME 3.4, there are certain requirements and they sometimes change. We should work together and reach out though to affected parties... and IMO well known that I/release team could improve on that. Fortunately 3.4 is not out yet. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, Jan 20, 2012 at 02:49:01PM +, Bastien Nocera wrote: > I think that's enough time to implement the functionality. I'd like to see that distributor-list used when a decision is reached. I guess this is a task for the release-team. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 14:48 +, Maciej Marcin Piechotka wrote:
> On Fri, 2012-01-20 at 09:45 -0500, Colin Walters wrote:
> > On Fri, 2012-01-20 at 12:24 +, Maciej Marcin Piechotka wrote:
> >
> > > The 0.6 branch is the stable one while 0.7 have not stabilised API/ABI
> > > (with expected breaks). I would advice to either follow 0.6 series or
> > > 0.6 branch (not master) until 0.7 will get stable API.
> >
> > Ah, ok - that's what I need to know. So we should definitely be
> > sticking with 0.6 for GNOME 3.4. And it looks like you have a 0.6
> > branch which is good - I want to track git, not a tarball snapshot.
> >
>
> Yes. 0.6 is still maintained. There should be a bugfix release during
> this weekend (I need just an advice from gir specialist about
> shared-library attribute of .typelib. Whom should I contact?)
You're talking to him now =) What's the question?
> also
> allowing building against vala master.
How about this patch (I am a Vala noob, but I want to try to pitch in
here rather than talk endlessly)
There are a *ton* of compiler warnings but it builds, ship it etc...
>From 5e35da9f6bbcb99790efb8934c9651e93f095d7c Mon Sep 17 00:00:00 2001
From: Colin Walters
Date: Fri, 20 Jan 2012 09:49:49 -0500
Subject: [PATCH] Fix compilation with Vala 0.15
---
gee/priorityqueue.vala |4 ++--
tests/testarraylist.vala |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gee/priorityqueue.vala b/gee/priorityqueue.vala
index 6c45238..e3e7a85 100644
--- a/gee/priorityqueue.vala
+++ b/gee/priorityqueue.vala
@@ -53,7 +53,7 @@ public class Gee.PriorityQueue : Gee.AbstractQueue {
private Type2Node? _lm_head = null;
private Type2Node? _lm_tail = null;
private Type1Node? _p = null;
- private Type1Node?[] _a = new Type1Node[0];
+ private Type1Node?[] _a = new Type1Node?[0];
private NodePair? _lp_head = null;
private NodePair? _lp_tail = null;
private bool[] _b = new bool[0];
@@ -316,7 +316,7 @@ public class Gee.PriorityQueue : Gee.AbstractQueue {
_lm_head = null;
_lm_tail = null;
_p = null;
- _a = new Type1Node[0];
+ _a = new Type1Node?[0];
_lp_head = null;
_lp_tail = null;
_b = new bool[0];
diff --git a/tests/testarraylist.vala b/tests/testarraylist.vala
index e5340c5..05bc328 100644
--- a/tests/testarraylist.vala
+++ b/tests/testarraylist.vala
@@ -148,9 +148,9 @@ public class ArrayListTests : ListTests {
assert (double_list.add (1.5d));
assert (double_list.add (2.0d));
- double[] double_array = double_list.to_array ();
+ double?[] double_array = double_list.to_array ();
index = 0;
- foreach (double element in double_list) {
+ foreach (double? element in double_list) {
assert (element == double_array[index++]);
}
}
--
1.7.6.5
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, Jan 20, 2012 at 03:06:45PM +0100, Sebastien Bacher wrote: > Ok, so as a distributor of GNOME I think that what we (Ubuntu) would > like to see: Agree fully.. is what I meant with the other email (which I sent before reading this one). I think we should put that somewhere in our standard schedule (the http://www.gnome.org/start/unstable one). -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 15:06 +0100, Sebastien Bacher wrote: > Le 20/01/2012 13:00, Olav Vitters a écrit : > > It is called systemd, and it is NOT a dependency. What we depend on is > > a few simple dbus APIs. If an OS doesn't implement those APIs, certain > > functionality won't work. These APIs have been implemented in systemd, > > but they can (and are being) implemented elsewhere. > > > > What I've said above is nothing new btw (to me). It has been discussed > > openly, think on this mailing list. > > > > What I am suggesting now is that we clearly document this (depend on the > > API being implemented). > Hi, > > Ok, so as a distributor of GNOME I think that what we (Ubuntu) would > like to see: > - some public list of what services GNOME rely on to be fully working > - some public announce earlier in the cycle, or if possible one cycle in > advance of what API will need to be provided for the next GNOME release > to be fully working > - some details (spec?) about the API used for those who want to > implement compatible ones > > It's fine to be using new services but if GNOME wants distributors to > provide a good GNOME experience system requirements should be announced > in advances with a clear description of the protocol to give enough time > to integrators to work on providing those services. Most of them are listed in the page that Olav pointed to: https://live.gnome.org/PortabilityMatrix Not updating it for the latest changes is my mistake. The actual talk of using systemd's timedated and localed services was in May 2011: http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00429.html And the bugzilla itself (for which you receive notification mails) opened since September. I think that's enough time to implement the functionality. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On 20 January 2012 08:47, Ryan Lortie wrote: > hi Bastien, > > On Fri, 2012-01-20 at 12:36 +, Bastien Nocera wrote: >> No, the distributions/systems that choose not to use systemd will have >> to provide a compatible D-Bus service. > > This is what I guessed you'd say. > >> It can be something "extracted" from systemd, or something new and >> revived from the old date and time mechanism, but it won't be something >> we support and maintain in gnome-settings-daemon. > >> And I'm glad I have 3000 less lines code to maintain. > > I'm just a little bit concerned about how this looks. I love when we > can delete code, but we're doing it by disabling a previously-working > feature for a portion of our users. > > If we introduced new optional features that depended on a particular > systemd functionality in order to operate, it would be one thing. We do > that often. This change is a regression of existing functionality in > the name of "I don't feel like maintaining it anymore". > > I'd also feel a bit better if I thought you had made efforts to get in > touch with those that would be affected by this regression. Ubuntu > isn't shipping GNOME 3.4 g-s-d/g-c-c, this cycle, for example, but for > the last week I've been trying to convince them that they should. If I > had succeeded (which I am now glad I didn't) then this change would have > been a royal pain, creating a whole lot of new work to fit into an > already full schedule. > > Many of our own end-users will still want to install GNOME 3.4 onto > their Ubuntu systems (myself included). I look forward to the mention > in our release notes about how they can no longer change their time > because we wanted to delete a bit of code. I agree with desrt. I've been actively working to package the parts of GNOME 3.4 that won't make it into the next Ubuntu release so that people that want the latest GNOME can have easy access to it via a PPA. While writing the extra code that Debian and Ubuntu will need may only take a day or a few days' work for you, it's probably beyond my abilities. I was going to make a final request before Ubuntu's feature freeze for g-c-c/g-s-d 3.4 to be reconsidered since it works except for some minor work needed in lightdm and unity. That work will have to be done anyway if we even want g-c-c 3.4 to be made available in the extra PPA. Dropping support for Debian & Ubuntu doesn't seem a very friendly move, and it's only going to delay getting GNOME 3.4 into the hands of your user base. Jeremy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 09:45 -0500, Colin Walters wrote: > On Fri, 2012-01-20 at 12:24 +, Maciej Marcin Piechotka wrote: > > > The 0.6 branch is the stable one while 0.7 have not stabilised API/ABI > > (with expected breaks). I would advice to either follow 0.6 series or > > 0.6 branch (not master) until 0.7 will get stable API. > > Ah, ok - that's what I need to know. So we should definitely be > sticking with 0.6 for GNOME 3.4. And it looks like you have a 0.6 > branch which is good - I want to track git, not a tarball snapshot. > Yes. 0.6 is still maintained. There should be a bugfix release during this weekend (I need just an advice from gir specialist about shared-library attribute of .typelib. Whom should I contact?) also allowing building against vala master. > I'll fix up the moduleset and work with the folks people on 0.15 > support. > > Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 12:24 +, Maciej Marcin Piechotka wrote: > The 0.6 branch is the stable one while 0.7 have not stabilised API/ABI > (with expected breaks). I would advice to either follow 0.6 series or > 0.6 branch (not master) until 0.7 will get stable API. Ah, ok - that's what I need to know. So we should definitely be sticking with 0.6 for GNOME 3.4. And it looks like you have a 0.6 branch which is good - I want to track git, not a tarball snapshot. I'll fix up the moduleset and work with the folks people on 0.15 support. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 08:47 -0500, Ryan Lortie wrote:
> hi Bastien,
>
> On Fri, 2012-01-20 at 12:36 +, Bastien Nocera wrote:
> > No, the distributions/systems that choose not to use systemd will have
> > to provide a compatible D-Bus service.
>
> This is what I guessed you'd say.
Why did you ask then? :)
> > It can be something "extracted" from systemd, or something new and
> > revived from the old date and time mechanism, but it won't be something
> > we support and maintain in gnome-settings-daemon.
>
> > And I'm glad I have 3000 less lines code to maintain.
>
> I'm just a little bit concerned about how this looks. I love when we
> can delete code, but we're doing it by disabling a previously-working
> feature for a portion of our users.
>
> If we introduced new optional features that depended on a particular
> systemd functionality in order to operate, it would be one thing. We do
> that often. This change is a regression of existing functionality in
> the name of "I don't feel like maintaining it anymore".
No, it's a different API, so I would have needed to rewrite the code to
support the new API anyway. And I would have needed to rewrite most of
it to use GDBus instead of dbus-glib.
> I'd also feel a bit better if I thought you had made efforts to get in
> touch with those that would be affected by this regression. Ubuntu
> isn't shipping GNOME 3.4 g-s-d/g-c-c, this cycle, for example, but for
> the last week I've been trying to convince them that they should. If I
> had succeeded (which I am now glad I didn't) then this change would have
> been a royal pain, creating a whole lot of new work to fit into an
> already full schedule.
What about the schedule of the gnome-control-center maintainers? I have
other things to work on too.
This particular change was mentioned nearly a year ago on this very same
list. It's not my fault Ubuntu (in this particular case) didn't take the
hint to start packaging the relevant D-Bus services, or rewriting them
to fit their use.
> Many of our own end-users will still want to install GNOME 3.4 onto
> their Ubuntu systems (myself included). I look forward to the mention
> in our release notes about how they can no longer change their time
> because we wanted to delete a bit of code.
You're making a fuss because you ("Ubuntu") didn't plan ahead. No, I
didn't do this to piss off Ubuntu or Canonical, because I have better
things to do, like writing GNOME code.
Stop this us vs. them thing, and get them to package up the missing
bits. An afternoon's work, and no need to scream bloody murder.
/Bastien, getting frankly annoyed
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 07:30 -0500, Matthias Clasen wrote: > > On 01/19/2012 10:32 PM, Colin Walters wrote: > >> > >> But others (folks at least) fail to compile with 0.15. > > > > > > This question might seem a little naive, but could someone highlight me why > > the vala compiler can't stay backward compatible from release to release? > > Indeed. Until vala grows up a little more, its increasing use in the > desktop is a growing problem. I wouldn't say that - vala is widely used because people clearly find it useful. We clearly need some more communication here though (and more people using jhbuild to build their vala modules trackin 3.4). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le 20/01/2012 13:00, Olav Vitters a écrit : It is called systemd, and it is NOT a dependency. What we depend on is a few simple dbus APIs. If an OS doesn't implement those APIs, certain functionality won't work. These APIs have been implemented in systemd, but they can (and are being) implemented elsewhere. What I've said above is nothing new btw (to me). It has been discussed openly, think on this mailing list. What I am suggesting now is that we clearly document this (depend on the API being implemented). Hi, Ok, so as a distributor of GNOME I think that what we (Ubuntu) would like to see: - some public list of what services GNOME rely on to be fully working - some public announce earlier in the cycle, or if possible one cycle in advance of what API will need to be provided for the next GNOME release to be fully working - some details (spec?) about the API used for those who want to implement compatible ones It's fine to be using new services but if GNOME wants distributors to provide a good GNOME experience system requirements should be announced in advances with a clear description of the protocol to give enough time to integrators to work on providing those services. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
hi Bastien, On Fri, 2012-01-20 at 12:36 +, Bastien Nocera wrote: > No, the distributions/systems that choose not to use systemd will have > to provide a compatible D-Bus service. This is what I guessed you'd say. > It can be something "extracted" from systemd, or something new and > revived from the old date and time mechanism, but it won't be something > we support and maintain in gnome-settings-daemon. > And I'm glad I have 3000 less lines code to maintain. I'm just a little bit concerned about how this looks. I love when we can delete code, but we're doing it by disabling a previously-working feature for a portion of our users. If we introduced new optional features that depended on a particular systemd functionality in order to operate, it would be one thing. We do that often. This change is a regression of existing functionality in the name of "I don't feel like maintaining it anymore". I'd also feel a bit better if I thought you had made efforts to get in touch with those that would be affected by this regression. Ubuntu isn't shipping GNOME 3.4 g-s-d/g-c-c, this cycle, for example, but for the last week I've been trying to convince them that they should. If I had succeeded (which I am now glad I didn't) then this change would have been a royal pain, creating a whole lot of new work to fit into an already full schedule. Many of our own end-users will still want to install GNOME 3.4 onto their Ubuntu systems (myself included). I look forward to the mention in our release notes about how they can no longer change their time because we wanted to delete a bit of code. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 15:13, Ionut Biru (io...@archlinux.ro) wrote: > I know the discussion and if I'm not wrong, the overall conclusion was a > big no no no to systemd. > > Also Lennart promised that providers can be used standalone and > absolutely no effort was made to ensure that and packaging separately > will require some hacking to the build systems. I did? I am pretty sure I didn't, why would I bother? Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On 01/20/2012 03:06 PM, Bastien Nocera wrote: > On Fri, 2012-01-20 at 13:23 +0200, Ionut Biru wrote: >> On 01/20/2012 10:34 AM, Olav Vitters wrote: >>> On Fri, Jan 20, 2012 at 08:04:36AM +, Emmanuele Bassi wrote: On 20 January 2012 03:25, Lennart Poettering 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 want to sound picky, but since when SystemD is a blessed dependency? > > It's an external dependency, since we discussed it in spring 2011, in > this thread: > http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html > I know the discussion and if I'm not wrong, the overall conclusion was a big no no no to systemd. Also Lennart promised that providers can be used standalone and absolutely no effort was made to ensure that and packaging separately will require some hacking to the build systems. > And we don't depend on systemd (otherwise there are patches in > gnome-settings-daemon and gnome-control-center for which we could remove > the #ifdef's), we depend on a D-Bus service being present, which is > shipped by systemd. > > Cheers > -- Ionuț ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 13:57 +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 > > > > 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). I'm sure the work can be reused to "port" the systemd service to OpenBSD (and port hostnamed too!). > > I've updated the page to link to timedated from systemd now. > > Thanks. > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 13:23 +0200, Ionut Biru wrote: > On 01/20/2012 10:34 AM, Olav Vitters wrote: > > On Fri, Jan 20, 2012 at 08:04:36AM +, Emmanuele Bassi wrote: > >> On 20 January 2012 03:25, Lennart Poettering 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 want to sound picky, but since when SystemD is a blessed dependency? It's an external dependency, since we discussed it in spring 2011, in this thread: http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html And we don't depend on systemd (otherwise there are patches in gnome-settings-daemon and gnome-control-center for which we could remove the #ifdef's), we depend on a D-Bus service being present, which is shipped by systemd. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://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 > > > > 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
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
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 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). > I've updated the page to link to timedated from systemd now. Thanks. -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On 2012-01-20 at 13:23, Ionut Biru wrote: > 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 want to sound picky, but since when SystemD is a blessed dependency? the dependency is not on systemd - it's on a DBus API. systemd provides one implementation of that DBus API. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
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 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. I've updated the page to link to timedated from systemd now. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On vie, 2012-01-20 at 04:25 +0100, Lennart Poettering wrote: > On Thu, 19.01.12 17:49, Ryan Lortie (de...@desrt.ca) wrote: > > > > > hi Bastien, > > > > On Thu, 2012-01-19 at 22:38 +, Bastien Nocera wrote: > > > commit 27fa171efe4179c0a42ec79e0dc501077f042a08 > > > Author: Bastien Nocera > > > Date: Thu Jan 19 22:33:21 2012 + > > > > > > datetime: Remove datetime D-Bus mechanism > > > > > > 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 > IIRC, the datetime one wasn't added, but yes, it should be added quite easily, as it was done with the other DBus interfaces ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Thu, 2012-01-19 at 17:49 -0500, Ryan Lortie wrote: > hi Bastien, > > On Thu, 2012-01-19 at 22:38 +, Bastien Nocera wrote: > > commit 27fa171efe4179c0a42ec79e0dc501077f042a08 > > Author: Bastien Nocera > > Date: Thu Jan 19 22:33:21 2012 + > > > > datetime: Remove datetime D-Bus mechanism > > > > 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? No, the distributions/systems that choose not to use systemd will have to provide a compatible D-Bus service. It can be something "extracted" from systemd, or something new and revived from the old date and time mechanism, but it won't be something we support and maintain in gnome-settings-daemon. FWIW, the old backend supported Fedora, SUSE and Debian systems, nothing else. So the portability problem would have happened on other systems (such as the *BSDs or Solaris), whether or not we made those changes. And I'm glad I have 3000 less lines code to maintain. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On 20 January 2012 12:25, Maciej Marcin Piechotka wrote: > It's included by default in new automake: > > AM_PROG_VALAC([0.14.0]) > > (checks for valac >= 0.14.0). Does that also check for valac-0.14 when valac doesn't exist? Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
> On 01/19/2012 10:32 PM, Colin Walters wrote: >> >> But others (folks at least) fail to compile with 0.15. > > > This question might seem a little naive, but could someone highlight me why > the vala compiler can't stay backward compatible from release to release? Indeed. Until vala grows up a little more, its increasing use in the desktop is a growing problem. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Fri, 2012-01-20 at 11:49 +0100, Matteo Settenvini wrote: > Il giorno gio, 19/01/2012 alle 16.32 -0500, Colin Walters ha scritto: > > However, modules will need to be patched to find the correct valac and > > vapigen with the -0.14 suffix. For example, folks just does: > > > > AC_PATH_PROG([VAPIGEN], [vapigen], []) > > if test "x$VAPIGEN" = "x"; then > > AC_MSG_ERROR([Vala must be built with --enable-vapigen]) > > fi > > > > We could manually pass VALAC=valac-0.14 VAPIGEN=vapigen-0.14 to > > configure, but it's probably better to fix this inside the configure > > scripts. > > > > Wouldn't it be a good idea for Vala to install a valac.m4 file > in /usr/share/aclocal, containing a pertaining macro? > > Something like AC_PROG_VALA([== 0.15]), so that everyone can use the > same macro, avoiding this kind of duplication and differences among > modulesets. This can set variables for both valac and vapigen in one go. > > Cheers, It's included by default in new automake: AM_PROG_VALAC([0.14.0]) (checks for valac >= 0.14.0). Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Thu, 2012-01-19 at 18:34 -0500, Colin Walters wrote: > On Thu, 2012-01-19 at 22:53 +, Philip Withnall wrote: > > > Also, I don't think there are any reasons for us to not port to Vala > > 0.15, as long as libgee 0.6 continues to compile with 0.15. > > Currently it seems to be broken for master (IIRC it worked for 0.15.0) and I'm working on fixing it. > > In fact, some of my recent folks branches require Vala 0.15 (due > > to .vapi file changes which haven't been backported to 0.14). > > Ah...okay so this raises another question I have - can someone fill me > in on why the 3.4 moduleset is stuck on libgee 0.6.2.1? > > Are you guys using jhbuild for 3.4? > > In the big picture where I'd like to be is that git master of all of > these modules are targeted for the 3.4 release. Or if for some reason > you don't want to synchronize to the GNOME schedule, at least have a 3.4 > branch. The 0.6 branch is the stable one while 0.7 have not stabilised API/ABI (with expected breaks). I would advice to either follow 0.6 series or 0.6 branch (not master) until 0.7 will get stable API. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://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:23:23PM +0200, Ionut Biru wrote: > > I guess we need to review, expand and announce the following again: > > https://live.gnome.org/PortabilityMatrix > > > > I don't want to sound picky, but since when SystemD is a blessed dependency? It is called systemd, and it is NOT a dependency. What we depend on is a few simple dbus APIs. If an OS doesn't implement those APIs, certain functionality won't work. These APIs have been implemented in systemd, but they can (and are being) implemented elsewhere. What I've said above is nothing new btw (to me). It has been discussed openly, think on this mailing list. What I am suggesting now is that we clearly document this (depend on the API being implemented). -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On 01/20/2012 10:34 AM, Olav Vitters wrote: > On Fri, Jan 20, 2012 at 08:04:36AM +, Emmanuele Bassi wrote: >> On 20 January 2012 03:25, Lennart Poettering 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 want to sound picky, but since when SystemD is a blessed dependency? -- Ionuț ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
Il giorno gio, 19/01/2012 alle 16.32 -0500, Colin Walters ha scritto: > However, modules will need to be patched to find the correct valac and > vapigen with the -0.14 suffix. For example, folks just does: > > AC_PATH_PROG([VAPIGEN], [vapigen], []) > if test "x$VAPIGEN" = "x"; then > AC_MSG_ERROR([Vala must be built with --enable-vapigen]) > fi > > We could manually pass VALAC=valac-0.14 VAPIGEN=vapigen-0.14 to > configure, but it's probably better to fix this inside the configure > scripts. > Wouldn't it be a good idea for Vala to install a valac.m4 file in /usr/share/aclocal, containing a pertaining macro? Something like AC_PROG_VALA([== 0.15]), so that everyone can use the same macro, avoiding this kind of duplication and differences among modulesets. This can set variables for both valac and vapigen in one go. Cheers, -- Matteo Settenvini FSF Associated Member Email : mat...@member.fsf.org -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/E d--(-) s+: a- C+++ UL+++ P+ L>$ E++>+++ W+++ N+ o? w--- O M- V- PS++ PE- Y+>++ PGP+++ t++ 5 X- R+ !tv b+++ DI++ D++ G++ e++ h+ r++ y+ --END GEEK CODE BLOCK-- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, Jan 20, 2012 at 08:04:36AM +, Emmanuele Bassi wrote: > On 20 January 2012 03:25, Lennart Poettering 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 -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
hi; On 20 January 2012 03:25, Lennart Poettering 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?" ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
