Re: external dependency review for 2.91
On 07/10/10 13:32, Frederic Peters wrote: Hi Martyn, Hi, SQLite is considered an external dependency, so it is defined in the gnome-external-deps-3.0.modules moduleset file; I'd say you should go ahead and update it, but do note there is currently a patch, sqlite-3.6.22.dlsym.patch, if necessary you should also update it. Thanks, noted and updated. -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependency review for 2.91
On 04/10/10 16:33, Martyn Russell wrote:
On 01/10/10 03:44, Matthias Clasen wrote:
Hi,
Hi,
I looked over the external dependencies for 2.91 [1]. I've bumped
the recommended versions to current versions in many places. There are
some places where we need to bump mnimal versions:
Yes, tracker is definitely one of those. Actually we've had a few
comments about this in the past. I will find some time to update it
soon. As per our discussion on IRC, I plan to make the version 0.9.x
with a view to bumping it to 0.10 in the next month or so.
OK, just to let everyone know. Tracker now builds in jhbuild for me. To
get there the following changes were made:
- D-Bus requires is now 1.4.0 was 1.2.x (for FD passing in Tracker)
- SQLite required is now 3.7.1, patches updated to fix missing -ldl
- Poppler autogenargs added --enable-xpdf-headers for PDF extraction
- Tracker version updated to 0.9.24 from 0.8.6
All changes are in gnome-{suites-core-}external-deps-3.0 modulesets.
Any problems, let me know.
--
Regards,
Martyn
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependency review for 2.91
On Mon, Oct 11, 2010 at 7:50 AM, Martyn Russell mar...@lanedo.com wrote:
On 04/10/10 16:33, Martyn Russell wrote:
OK, just to let everyone know. Tracker now builds in jhbuild for me. To get
there the following changes were made:
- D-Bus requires is now 1.4.0 was 1.2.x (for FD passing in Tracker)
- SQLite required is now 3.7.1, patches updated to fix missing -ldl
- Poppler autogenargs added --enable-xpdf-headers for PDF extraction
- Tracker version updated to 0.9.24 from 0.8.6
All changes are in gnome-{suites-core-}external-deps-3.0 modulesets.
Thanks. I don't think bumping the dbus minimal version to 1.4.0 should
be a problem.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: package dependencies
On Sun, Oct 10, 2010 at 4:18 PM, Milan Bouchet-Valat nalimi...@club.fr wrote: Le dimanche 10 octobre 2010 à 16:12 -0400, Kevin McKinney a écrit : Dude, it's Sunday! On weekdays, he's usually on #gnome-hackers (even if he's quite busy ;-). But he's surely going to notice this thread too. I will try to contact him again this week; and I will be sure to limit my communications on the weekends. $ dpkg -S dbus-glib-lowlevel.h libdbus-glib-1-dev: /usr/include/dbus-1.0/dbus/dbus-glib-lowlevel.h So you also need libdbus-glib-1-dev. Thanks for the information; you have been very helpful. Thanks, Kevin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome2 and gnome3: strategy of coexisting
Hi folks I am not sure if I missed that topic (apologies if I did). Is there a strategy regarding co-existing of gnome2 and gnome3 on the same system? Obviously there is going to be some transitional period, when people would play with two generations. Distributions might want to have two sets of packages (two entries in gdm sessions list). So, is gnome going to address that - or just leave it to distromakers? Of course, we know distromakers are creative, they'll go for something like /opt/gnome3 and /opt/gnome2, tweaking PATH etc etc - but every distro is going to do that differently. Are we happy about that - or perhaps we could make their life easier by introducing some recommendations, conventions? Resolving that issue could also help developers to live in stable gnome2 while doing things for gnome3. I will narrow my question a bit. Some components, like gnome-session, gnome-settings-daemon etc for a moment are using same names as they did in gnome2. Would it make sense resolve that collision by using different names (most simple way - adding 3 add the end)? I am not concerned about creating a bad practice here: gnome2 was evolving for decade, and I hope gnome3 would be around for another decade (and who knows - will gnome4 ever exist?;). What do you think? Does my question make any sense at least? Thanks, Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
First I should say that I think this all look very good. Considering the proposed goals and the previous feedback, I think you have come up with some elegant solutions. Cheers. + we strongly encourage the application developers to follow the GNOME development cycle. If a different development cycle is used, it has to be documented to help contributors. If you remember from the previous discussions, this is a sensitive subject from a translations resource/translation completeness point of view. The objections were that having a large group of applications (I use the term widely), that has a well defined and common release schedule, makes for a easily definable goals and makes it easy to maximize translation performance with limited resources. This objection still stands, strongly encouraging, does not give me a guarantee against untimely string changes and the concomitant loss of work, the way that the current workflow for the desktop module set to a very large degree does. However, if I try to look at this from a broader perspective, I do see some convincing greater good arguments for this decision. So although the objection is still valid, I think the proposed solution is a worthwhile compromise. (Lets just hope that strongly encourage means way more than 75% of the projects will follow, and not, like I may fear, less than 25% :)) I would like to elaborate on one very important thing that you mention, and that is that if a project chooses not to follow the GNOME release schedule, the key is information. So when/(if) this happens it has to be extremely visibly, preferably right there in l10n.org. So I would suggest as a technical detail to your proposal, that it is a _requirement_ for project maintainers of projects that don't follow the GNOME release schedule, to not only document it in their development fora, but also to publish a (tentative) string freeze and release date somewhere in the repository, so that it can be automatically parsed and published on damned lies. With regards to external translation tools I will reply in the new thread Andre has started. Regards Kenneth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome2 and gnome3: strategy of coexisting
On Mon, 2010-10-11 at 22:16 +0100, Sergey Udaltsov wrote: Hi folks I am not sure if I missed that topic (apologies if I did). Is there a strategy regarding co-existing of gnome2 and gnome3 on the same system? Short answer is no, and we won't be doing it. I will narrow my question a bit. Some components, like gnome-session, gnome-settings-daemon etc for a moment are using same names as they did in gnome2. Would it make sense resolve that collision by using different names (most simple way - adding 3 add the end)? I am not concerned about creating a bad practice here: gnome2 was evolving for decade, and I hope gnome3 would be around for another decade (and who knows - will gnome4 ever exist?;). What do you think? Does my question make any sense at least? When people talk about Classic GNOME wrt GNOME 3, they mean the ported to GTK+ 3.x, updated to GSettings, parts of the GNOME 2.x experience. There are no plans to make gnome-settings-daemon, bits of the control-center, and whatever else core components of the desktop parallel installable. The libraries will be parallel installable so you can run your not-ported-yet applications, but core parts of the desktop won't be one of them. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome2 and gnome3: strategy of coexisting
Thanks for the answer. So, does that mean we directly or indirectly recommend to distromakers NOT to allow users to choose between gnome2 (real, not (panel + nautilus)/gnome3) and gnome3 sessions? Does that mean we recommend not to bother creating two sets of packages? Or we are just neutral and do not care (and we do not help)? On Mon, Oct 11, 2010 at 10:23 PM, Bastien Nocera had...@hadess.net wrote: On Mon, 2010-10-11 at 22:16 +0100, Sergey Udaltsov wrote: Hi folks I am not sure if I missed that topic (apologies if I did). Is there a strategy regarding co-existing of gnome2 and gnome3 on the same system? Short answer is no, and we won't be doing it. I will narrow my question a bit. Some components, like gnome-session, gnome-settings-daemon etc for a moment are using same names as they did in gnome2. Would it make sense resolve that collision by using different names (most simple way - adding 3 add the end)? I am not concerned about creating a bad practice here: gnome2 was evolving for decade, and I hope gnome3 would be around for another decade (and who knows - will gnome4 ever exist?;). What do you think? Does my question make any sense at least? When people talk about Classic GNOME wrt GNOME 3, they mean the ported to GTK+ 3.x, updated to GSettings, parts of the GNOME 2.x experience. There are no plans to make gnome-settings-daemon, bits of the control-center, and whatever else core components of the desktop parallel installable. The libraries will be parallel installable so you can run your not-ported-yet applications, but core parts of the desktop won't be one of them. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome2 and gnome3: strategy of coexisting
On Mon, Oct 11, 2010 at 10:37:36PM +0100, Sergey Udaltsov wrote: Thanks for the answer. So, does that mean we directly or indirectly recommend to distromakers NOT to allow users to choose between gnome2 (real, not (panel + nautilus)/gnome3) and gnome3 sessions? Does that mean we recommend not to bother creating two sets of packages? Or we are just neutral and do not care (and we do not help)? I don't expect anyone @ GNOME to care about 2.x. Distributions can do what they want, but need to take that into account. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome2 and gnome3: strategy of coexisting
Personally, I feel that is wrong - that kind of attitude to 2.x. It is (not was!) a stable and solid foundation. While we are floating into new and dangerous waters of 3.x (still risking getting into the situation KDE folks had: KDE 4.0 != KDE4), at least we could make a couple of small things here and there - allowing them to coexist, for smoother transition. I know that is always a question of resources, as usual - but if some things cost nothing, why not buy them? Sergey PS I am already missing 2.x. That's just my conservatism - but I know a lot of users are like me. People like me would not mind seeing 2.34, 2.36, ...2.98, 2.100, 2.102, ... - just less bugs and a wee bit of more features, here and there;) On Mon, Oct 11, 2010 at 11:06 PM, Olav Vitters o...@vitters.nl wrote: On Mon, Oct 11, 2010 at 10:37:36PM +0100, Sergey Udaltsov wrote: Thanks for the answer. So, does that mean we directly or indirectly recommend to distromakers NOT to allow users to choose between gnome2 (real, not (panel + nautilus)/gnome3) and gnome3 sessions? Does that mean we recommend not to bother creating two sets of packages? Or we are just neutral and do not care (and we do not help)? I don't expect anyone @ GNOME to care about 2.x. Distributions can do what they want, but need to take that into account. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome2 and gnome3: strategy of coexisting
On Mon, 2010-10-11 at 22:37 +0100, Sergey Udaltsov wrote: Thanks for the answer. So, does that mean we directly or indirectly recommend to distromakers NOT to allow users to choose between gnome2 (real, not (panel + nautilus)/gnome3) and gnome3 sessions? Does that mean we recommend not to bother creating two sets of packages? Or we are just neutral and do not care (and we do not help)? I think it was pretty clear from the start that we were going to carry, for a little while at least, 2 experiences. There will be the GNOME 3 experience, with the new gnome-shell, control-center, and changes to core desktop, and there will be a classic experience, which would use the same core components, but with the panel and metacity instead of the shell. In the long run, the classic view will go, but the main point is that this experience, while it exists, will be based on the same technology as the rest of GNOME 3. So there shouldn't be any need to ship a GNOME 2.x panel, nautilus, or whatever else core component. The applications should carry on working if the distributors ship with the older versions of the libraries. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome2 and gnome3: strategy of coexisting
On Mon, Oct 11, 2010 at 11:20:04PM +0100, Sergey Udaltsov wrote: Personally, I feel that is wrong - that kind of attitude to 2.x. It is (not was!) a stable and solid foundation. While we are floating into new and dangerous waters of 3.x (still risking getting into the situation KDE folks had: KDE 4.0 != KDE4), at least we could make a couple of small things here and there - allowing them to coexist, for smoother transition. I know that is always a question of resources, as usual - but if some things cost nothing, why not buy them? You will still have GNOME panel available. Other than that, loads of things will use gsettings instead of gconf. I don't see why'd you want GNOME 2.x? What is the point? Ensuring that distributions will at least show a few GNOME changes in April even if they don't want 3.0? We've already released 2.32 as an extra release just because GNOME 3.0 wasn't ready. Now everything is focussing finally more on really releasing 3.0. For 2.x we still have the 2.32.x releases. But backporting is to me not what focus should be upon. The 3.1/3.2 cycle will be shorter so distributions will more quickly get the feedback we will surely get from 3.0. If some distribution wants to handle this differently, they're free to 'git clone' and submit patches. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome2 and gnome3: strategy of coexisting
On Mon, 2010-10-11 at 23:38 +0100, Sergey Udaltsov wrote: Here you got me confused a bit. Does that mean that components used both in gnome3 and gnome3 classic should be able to behave differently depending on how they are used? From my perspective, I am asking about gnome-settings-daemon. The tiny bit of gnome that I maintain (kbd indicator) is implemented as GtkStatusIcon in gnome2. For proper gnome3 integration, I have to do some work to integrate it into gnome-shell. What about gnome3 classic mode? Should I maintain two variants? I do not think this is the only example of situation when the system components would behave differently depending on whether they are run within full or classic gnome3. Was that discussed before? I actually have that same problem with gnome-bluetooth, and gnome-media, and Richard with gnome-power-manager. They all provide core components, and all use status icons. For your gnome-settings-daemon code, just make sure that you keep the same name for the status icon (gnome-shell can hide certain status icons selectively), and help out implementing: http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/InputLanguage The system status icons live directly in gnome-shell, and, as long as you provide all the backing libraries with introspection enabled, I'm sure one of the shell hackers can help you out with implementing that menu. And anyway, gnome3 in classic mode is not the same thing as gnome2. The user experience would be as close as possible - but not the same, I suspect. And, what's worse, I do not expect the same the stability as gnome2 provides these days. So the possibility to have real gnome2 would be attractive for some while, I guess... You could also use GNOME 1.x, I'm sure that's solid... I'm not sure what you expect in terms of stability for our biggest release ever, and right in the middle of the development cycle. But, you actually answered that question already. I can dislike your answer, but perhaps it is a bit too late to express concerns. Translating from Russian: too late for the mineral water, the liver is already gone. GNOME 2.32.x will still be available, and bug fix releases made in due course, so distributions are free to ship that if they feel they want stability, knowing full well that their experience will be outdated as soon as shipped. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
