Re: Celebrating the release of GNOME 2.16!
Bastien Nocera wrote: On Wed, 2006-09-06 at 12:57 -0600, Elijah Newren wrote: == Celebrating the release of GNOME 2.16! == Today, the GNOME Project celebrates the release of GNOME 2.16, the latest version of the popular, multi-platform Free desktop environment. Released on schedule, to the day, it is the culmination of six months effort by GNOME contributors around the world: hackers, documentors, usability and accessibility specialists, translators, maintainers, sysadmins, companies, artists, users and testers. Due to their hard work, we have another great release to be proud of - thanks very much to every contributor! You'll find plenty of information about GNOME 2.16 in our extensive release notes, linked from the 2.16 start page. All about GNOME 2.16: http://www.gnome.org/start/2.16/ Not sure whether that's been reported before, but this page: http://www.gnome.org/start/2.16/notes/C/rnfeatures.html has broken images. eg.: The requested URL /start/2.16/notes/C/figures/rnfeatures-laptop.png was not found on this server. Cheers rant For the record, the release notes were really a sprint this year - I volunteered to convert the wiki pages to docbook, and ended up committing all the changes to CVS, setting up the build structure, and touching up and uploading all the images to be included (I obviously missed two). I didn't know the links to the release notes were going to be sent out today with the official release notification. In the future, we should set a specific timeline for the release notes and a deadline for comments on a final draft, and a freeze for translation right before the release. Additionally, we may need help to put PO files on the documentation status page, so that translators can easily access them. /rant Anyway, happy GNOME 2.16 release! -- Brent Smith [EMAIL PROTECTED] IRC: smitten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
hal and jhbuild
I'm going to commit a change to freedesktop.modules to checkout hal from the tag HAL_0_5_7_1 and add a patch to jhbuild to fix the two instances where dbus_connection_close() should be used. Unless anyone has any objections... -- Brent Smith [EMAIL PROTECTED] IRC: smitten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Patches for scrollkeeper...is scrollkeeper maintained?
Don Scorgie wrote: Hi, On Wed, 2006-07-26 at 14:17 -0600, Elijah Newren wrote: Hi, Does scrollkeeper have any maintainers? I just found out about a Funny that you bring this up, I was thinking about this yesterday. bunch of patches needed for yelp to not choke on scrollkeeper files, listed at http://live.gnome.org/Yelp (all of the patches are part of bug 348013). It appears that the gnome-2.16 jhbuild moduleset has been patched to manually include these, but it'd be better to just get them upstream...if there is still an upstream (last scrollkeeper release was 2003). Anyone know more about this? AFAICT, 'E's passed on! This parrot is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! It is really annoying. There have been at least a few bugs filed against yelp about scrollkeeper problems. The last non-spam message to their mailing list was a couple of years ago, and that appears to have been shaunm, basically asking what was happening (the answer was I don't know of any plans). The patches linked are all from the Ubuntu scrollkeeper package. Hopefully at some point soon, we can remove scrollkeeper entirely and replace it. There are secret plans afoot. Don In the meantime, why don't we just import 0.3.14 (the last released version) into GNOME CVS and apply critical patches there, and point jhbuild to that? Any objections? We may be able to get commit access from the current project admins at sourceforge, but I'm not aware of their policy on overtaking unmaintained projects without the original authors permission. Anyone want to volunteer? License appears to be GLPL so I don't think there are any problems with this right? -- Brent Smith [EMAIL PROTECTED] IRC: smitten / #docs / irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: CVS/JHBuild complaints
Luca Ferretti wrote: Il giorno sab, 22/07/2006 alle 12.48 -0600, Brent Smith ha scritto: This weekend I have tried to build Yelp and all it's dependencies from jhbuild. I ran in to quite a few problems, so I'm complaining publicly here (I know Jeff will hate me for this): * avahi depends on libgdbm; libgdbm-dev needs to be installed for avahi Do we currently have a list of external development libraries that need to be installed in order to compile from JHBuild? I know there are some recommendations at http://live.gnome.org/JhbuildOnUbuntu in the section How to prepare your system for Development? but this is 1) not distribution agnostic and 2) relatively unmaintained. Perhaps this could be one of the Build Brigade's responsibilities? (http://live.gnome.org/BuildBrigade) It's a wiki. Edit the page and add this info, please. There is this page too: http://live.gnome.org/JhbuildDependencies I've editted it for Dapper. It would be appreciated if people using other distributions could update the wiki for their particular distribution. I don't know if we care about prior versions of GNOME, but I was thinking it would be nice if this was a table layout, color coded to indicate which modules are required for which version. Then again, I don't know how many people are building older versions of GNOME from jhbuild/source... * avahi depends on libglade; need to modify the gnome-2.16 moduleset to reflect this dependency * avahi depends on pygtk (and pycairo, pygobject); need to modify gnome-2.16 moduleset to reflect this dependency Could you please open a bug for jhbuild-modulets (something like missing deps for avahi), write that info and add myself in CC? I'll fix this. bug filed as 348453 * avahi depends on dbus-python and dbus-glib bindings set; dbus-python and dbus-glib are now in a git repository (bug 347674); need to add to modulesets and add appropriate dependencies I've commited the patch just now. Unfortunately no way to build a python (setup.py) module in jhbuild.. Or not? Any info? There seems to be some preliminary support in jhbuild/modtypes/distutils.py. Can anyone comment here? (/me looks at James or Frederic) * dbus-python depends on Pyrex for bindings which aren't included in jhbuild bootstrap I don't think we need to put it in bootstrap, but yes, we need it. Unfortunately, as above, installation based on setup.py :-( My suggestion (and the proper solution, I think) is write this info in live.gnome.org/JhbuildIssues/* pages. Please create a new page for dbus-python and add here relevant info. (download Pyrex, unpack and run `jhbuild run python setup.py install`) Done. See http://live.gnome.org/JhbuildIssues/dbus-python * dbus-glib fails compilation due to automake failing because of a missing 'ChangeLog' (f.d.o bug 7540) * dbus-glib/test/glib/test-service-glib.h fails compilation due to a missing include file (f.d.o. bug 7589) * dbus-glib doesn't install dbus-glib.h include file (f.d.o. bug 7562) All fixed. So I commited the patch in bug 347674 (two bugs were still marked as NEW there, the other one was ASSIGNED but they all were fixed), *grumble* I marked 7540 and 7562 as fixed with links to gitweb commitdiffs. It looks like the tools subdir generates the dbus-glib-bindings.h file and needs a system message bus running, but it wants to use $prefix/var/run/dbus/system_bus_socket where $prefix = /opt/gnome2 [EMAIL PROTECTED]:/extra/cvs/gnome2/dbus-glib/tools$ make DBUS_TOP_BUILDDIR=.. dbus-send --system --print-reply=literal --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.Introspectable.Introspect dbus-bus-introspect.xml.tmp mv dbus-bus-introspect.xml.tmp dbus-bus-introspect.xml Failed to open connection to system message bus: Failed to connect to socket /opt/gnome2/var/run/dbus/system_bus_socket: No such file or directory I updated 7589 regarding this. * PolicyKit needs --disable-docbook-docs, or make fails due to missing command no (f.d.o. bug 7161) * PolicyKit needs --with-pam-module-dir=prefix + '/lib' so it doesn't try to install into /lib Add custom rules to general moduleset is not good IMHO. When, for istance, bug 7161 will be fixed, the custom rule to general moduleset will be deprecated. As above, open a page on live.gnome.org/JhbuildIssues/ See http://live.gnome.org/JhbuildIssues/PolicyKit * libvolume_id needs to be installed for hal; should this be part of jhbuild bootstrap or should the user be responsible for installing the development package from their distro? I ended up getting around this by doing the following: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/hal co -D 'Jul 10 18:30:00 2006 UTC' hal This is a serious issue. libvolume_id should be in udev 0.9x (or similar). So you should install it, maybe breaking your distro. Should we depend on latest HAL package? I suggest you to open a bug about i. bug 348465 Thank
Bug buddy maintainer? (Was Re: bug-buddy support)
Matthias Clasen wrote: On 7/21/06, Jason D. Clinton [EMAIL PROTECTED] wrote: On Fri, 2006-07-21 at 12:35 -0400, Matthias Clasen wrote: I noticed that bug-buddy refuses to file bugs against a number of core desktop applications (I just found yelp and evince). I think we should make an effort to ensure that all core desktop apps have the necessary information in their .desktop files by 2.16. I just noticed this as well. See bug #347679. Pardon my ignorance as I have just become the maintainer but, when did this change and what needs to be done? See, this is something that I would have expected the bug-buddy maintainers to announce to desktop-announce-list when they made these changes... When I was hacking on bug-buddy a few months ago, I noticed that it uses the gmenu API to find and add applications for which it reports bugs. Unfortunately, this causes problems for programs which are not included in the menus (like evince and yelp). I don't know if this is how bug-buddy worked with 2.14.0 or what, but I agree this is a rather large problem. One solution is to include our own bug-buddy.menu file without any filters, but this doesn't solve the issue for applications with NoDisplay=true in the .desktop file as I don't believe the gmenu API returns these applications. Bug-buddy is pretty much maintainerless from what I can tell - Fer is not very active, and I have my hands full with Yelp. Is there someone out there that would be interested in taking bug-buddy by both reins? -- Brent Smith [EMAIL PROTECTED] IRC: smitten / #docs / irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Alvaro Lopez Ortega wrote: Dan Winship wrote: [snip] And if your argument is really languages that come with their own frameworks are bad,and not just I hate mono, then why didn't you argue against allowing python-based apps in the platform when that came up a year and a half ago? I missed it. :-/ Actually, what is puzzling me is that nobody else did it. You cannot even imagine how many people think like this.. I guess there are too many interests around these adoptions, I don't know. In any case, IMHO using Python to develop basic desktops applications is as wrong as using Mono or any other framework. And, don't take me wrong. I said *basic* desktop applications. Projects like Alacarte are okay; those are applications that you may use once a week/month. However, when we speak about an applet that will be loaded each single time you boot for PC things change. We ought to be extra careful with those. I'm going to go ahead and pipe up here because I feel like I need to voice my opinion that Mono should _not_ be part of the core set of modules for the GNOME Desktop. This is for a number of concerns which have already been stated, but it boils down to 1) this is still too controversial of a topic to make a decision in a single six month release cycle (with only 3 or so months left) and 2) I think is a topic that should be left to ISVs to decide. That being said, I use tomboy/f-spot and I'm glad that a certain ISV packages Mono and applications based on it, but I don't see how adding it lends any coherence or consistency to the GNOME framework. -- Brent Smith [EMAIL PROTECTED] IRC: smitten / #docs ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Buildability of tarballs and cvs
Elijah Newren wrote: On 6/18/06, Jeff Waugh [EMAIL PROTECTED] wrote: Yes - shipping build fix patches is a *massive* regression in the release management process, cf. signature. snip Basically my philosophy on release management is that it should be like police brutality. - Maciej Stachowiak Well, we'll have to switch back to police brutality then. :-) Time for some beatings...the following issues are still relevant AFAICT: [snip] gnopernicus344695 can't find gdkx.h Invoking build sheriff privileges. 2006-06-20 Brent Smith [EMAIL PROTECTED] * configure.in: add GTK+ to PKG_CHECK_MODULES so the include path for GTK is specified in the cflags; patch from Elijah Newren, fixes #344695 -- Brent Smith [EMAIL PROTECTED] IRC: smitten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Crash reports from GNOME bindings
Fernando Herrera wrote: On 6/18/06, Gustavo Carneiro [EMAIL PROTECTED] wrote: This sounds like a very good idea. But could you give more details? What does the --include option accept? A string, file name, ...? I rather pass information through a pipe, really, anything else is bound to reach either a cmdline length limit, or force you to create a temporary file (if done wrong we'll be seeing those security fixes due to bad tmpfile handling in a few months). --include points to a filename including the trace. You have also a --kill pid command (not working yet) to get your application killed by bug-buddy after the bug report. I guess that getting a trace in python on mono is not as expensive as the gdb thing, so there would not be a big delay after the crash and the bug-buddy interface coming up. But if we have a big delay we could use instead a named pipe to feed the trace over it, so the bindings can call bug-buddy inmidiately and then getting/feeding the trace while bug-buddy shows the progress bar. What if bug-buddy accepted input from stdin with --include -? Then the caller could use g_spawn_async_with_pipes(). Any security implications there? -- Brent Smith [EMAIL PROTECTED] IRC: smitten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug buddy branched
This never made it to my mailbox, so I am resending. Brent Smith wrote: Bug buddy has been branched. gnome-2-14 branch is for the stable release HEAD has merged bug-buddy-xmlrpc branch and is where all new development will take place. -- Brent Smith [EMAIL PROTECTED] IRC: smitten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to add Orca to GNOME 2.16
Willie Walker wrote: [snip] 3. The current gap of the Configuration GUI is an issue. Orca configuration currently is done via a command line setup script, although Orca has also been designed to run w/o requiring setup. Post setup configuration is managed by hand editing a settings module. We realize the 1990's clunkiness of this, and we definitely plan resolve this with a real GUI. The main issue is getting the manpower and we welcome help from the community to do it in a timely manner. I still need to point out the irony of requiring a screen reader to configure your screen reader. ;-) I propose that we recognize that the Configuration GUI is a much needed thing, but we realize that the users have other accessible options for configuring Orca. As such, the lack of the GUI is a very small notch below show stopper status for GNOME 2.16, and is a must have for GNOME 2.18. While the GUI aspect may not make sense for the target audience, it makes sense for developers and other users who may support the interface. I also would love to see the documentation in the accessibility guide updated with instructions on how to use Orca. This document lives in gnome CVS as gnome-user-docs. Discussion takes place on gnome-doc-list. -- Brent Smith [EMAIL PROTECTED] IRC: smitten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Latest documenation
Murray Cumming wrote: On Sat, 2006-04-15 at 16:33 -0600, Brent Smith wrote: Latest documentation is now at http://www.gnome.org/learn/ PDFs are a minor version behind the html versions, which is something I hope to fix soon. THANK YOU. Is there a page on the wiki somewhere saying how you did this, and recommending how to do it regularly before each major GNOME release? Murray, No, but I can make one. The stylesheets are located in CVS module gnomeweb-wml/docbook_html_style/ and were used to create the html from the docs in gnome CVS module gnome-user-docs. I tar'd up the results and put them in my home dir on master.gnome.org and Olav put them in the proper location on the server (I couldn't do this as it requires the gnomeweb-wml user group, I need to request this). Then I changed the contents of the index.wml and added the archived.wml files in gnomeweb-wml/www.gnome.org/learn/. Where would the most appropriate place to make this be on the wiki? Here's the instructions from Olav: --- Note that the docs (not index.html/wml) itself must be updated on the server (the final html/pdf files are not in CVS). There doesn't seem to be script for it. Updating on the server can be done by anyone with access to the gnomeweb group (me, Elijah, not sure who else..). Sudo to gnomeweb. Then go to /usr/local/www/gnomeweb-wml.learn. Do an ls in that directory. The rest is easy (copy stuff there, extract, etc). To add another doc the server admins need to add an Alias for that directory in /etc/httpd/sites.d/00_gnome.org.conf (so that www.gnome.org/learn/new-doc will look in /usr/local/www/gnomeweb-wml.learn/new-doc). Needed because the index.html is still handled by the wml, so the entire /learn/ cannot just be aliased to /usr/local/www/gnomeweb-wml.learn Regards, Olav --- Brent Smith [EMAIL PROTECTED] IRC: smitten / irc.gnome.org / #docs ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2 infinity and beyond [was Re: Tango and 2.16]
Chris Lahey wrote: At conferences and LUGs, the marketing message is always about the 6 month release and the idea of just putting off features until the next version, but what if we combined the two ideas? Have a release every 6 months as we have been, but plan a set of features for 3.0 and when we hit that set of features, we change the numbering. Say we pick a set of features and in 2008 2.21 happens to match that set of features. Instead of going to 2.22, we go to 3.0. Nice and easy. Then we pick a set of features for 4.0 and so forth. What do y'all think? Chris [snip] I think if we are targeting features, one of them has to be a sane documentation system and better documentation[1] including information such as customization of GNOME for ISVs. IMHO, we can't even start to think about GNOME 3.0 (or otherwise) without addressing this issue. Shaun has thrown out quite a few ideas such as topic based help via Project Mallard[2], library.gnome.org, etc. Yelp has seen some love lately but is sorely in need of an API overhaul and we still depend on scrollkeeper which is a huge pain in the ass. Unfortunately, there is a lack of developer interest in this aspect of the desktop. Fixing this problem would be a great way to reinvent ourselves for a GNOME 3.0. I would like to encourage interested hackers to discuss on gnome-doc-devel-list. my three cents. -- Brent Smith [EMAIL PROTECTED] IRC: smitten [1] http://live.gnome.org/DeveloperGuides [2] http://live.gnome.org/ProjectMallard ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Latest documenation
Latest documentation is now at http://www.gnome.org/learn/ PDFs are a minor version behind the html versions, which is something I hope to fix soon. -- Brent Smith [EMAIL PROTECTED] IRC: smitten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome is a problem for OEMs
Scott J. Harmon wrote: Too bad that documentation is horribly out of date. Seems like nobody wants to contribute to documentation these days... Updated PDFs for 2.14 at http://www.gnome.org/~bmsmith/gnome-2-14-pdfs/ Check out system-admin-guide.pdf for information on how to edit menus. we should really get these on the main site -- Brent Smith [EMAIL PROTECTED] IRC: smitten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
PDFs for user-guide, accessibility-guide and system-admin-guide
I've been working on generating some new PDFs for the documentation in the gnome-user-docs package. I've come up with some build scripts[1] that generate some decent output using Apache's FOP and Norman Walsh's DocBook - XSL-FO stylesheets. The generated PDFs are available at: http://www.gnome.org/~bmsmith/user-guide.pdf http://www.gnome.org/~bmsmith/system-admin-guide.pdf http://www.gnome.org/~bmsmith/gnome-access-guide.pdf At this point, I would just like some feedback on these. I've ironed out most of what I think are the major issues, but I would like to hear comments about these, specifically related to formatting issues (since I know the content needs some work ;-) Although, really we have had some great work on the docs this cycle, thanks to some new contributors. [1] http://www.gnome.org/~bmsmith/gnomedocs-snapshot-20060307.tar.gz Thanks, -- Brent Smith [EMAIL PROTECTED] IRC: smitten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Document font pref [was: Re: asking for approval for bug 160454]]
Federico Mena Quintero wrote: Can we assume that Yelp will be done really soon? We are already half-frozen for this release cycle. Federico I'll commit the change to Yelp ASAP, but... How is this different from the font_name key? Is font_name intended for the GUI/GTK+ font, while document_font_name is for any other application in which you view a document? If gedit views documents, then why does it use the fixed width font instead of the document font? What about the dictionary applet, and other applications where the interface is similar to a document, should they use this key? I'm just worried about consistency. -- Brent Smith [EMAIL PROTECTED] IRC: smitten ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
