Re: update of jhbuild module dependencies
On Sat, Nov 8, 2008 at 3:06 PM, Luca Ferretti <[EMAIL PROTECTED]> wrote: > * a little mess with clutter stuff: we have "clutter" in >gnome-external-deps-2.26 (0.8.2 targz) and in gnome-2.26 (svn >trunk) and "clutter-0.8" (svn branch) as well as a lot of >"clutter-XXX-0.8": clutter 0.8.x is official external dep for >GNOME 2.24. Will we switch to 0.9/1.0 in 2.26? Emmanuele? No, 0.6.x is official external for 2.24. My request bumped that to 0.8 for 2.26. 1.0's release is scheduled too close to our freezes, I think. clutter-cairo, -gstream, -gtk, should all be set to the latest releases of those modules. 0.8.x is API stable. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: update of jhbuild module dependencies
Il giorno sab, 08/11/2008 alle 23.27 +0100, Frederic Peters ha scritto: > Luca Ferretti wrote: > > > > > * a little request: could we force to build "hicolor-icon-theme" > > > > before "gtk+"? This could be useful, for example if you use > > > > jhbuild to build just one application (for example `jhbuild > > > > build transmission`) and not the full desktop. The other > > > > solution is make all modules installing icons in > > > > $(prefix)/share/icons/hicolor depend on "hicolor-icon-theme" > > > > > > Maybe as ? > > > > I'm for , gtk+ don't strictly depends on hicolor > > But then it won't be built in your 'jhbuild build transmission' > example, as it wouldn't appear in the dependency chain. (while > would put it in it). Doh! Yeah, sorry, my misinterpretation of . Then we can only use for gtk+ or check all modules installing stuff in hicolor and make theme depend on hicolor-icon-theme... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: update of jhbuild module dependencies
Luca Ferretti wrote: > > > * a little request: could we force to build "hicolor-icon-theme" > > > before "gtk+"? This could be useful, for example if you use > > > jhbuild to build just one application (for example `jhbuild > > > build transmission`) and not the full desktop. The other > > > solution is make all modules installing icons in > > > $(prefix)/share/icons/hicolor depend on "hicolor-icon-theme" > > > > Maybe as ? > > I'm for , gtk+ don't strictly depends on hicolor But then it won't be built in your 'jhbuild build transmission' example, as it wouldn't appear in the dependency chain. (while would put it in it). Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: update of jhbuild module dependencies
Il giorno sab, 08/11/2008 alle 22.36 +0100, Frederic Peters ha scritto: > Luca Ferretti wrote: > > * WebKit missing in "meta-gnome-proposed" ?? note that WebKit will > > grab ~400 MB from git. > > * libunique missing in "meta-gnome-proposed" > > We do not list proposed external dependencies in meta-gnome-proposed; > unique and libproxy are already set in gnome-external-deps-2.26; > WebKit should be added. Oh, that's true, sorry. > > * a little request: could we force to build "hicolor-icon-theme" > > before "gtk+"? This could be useful, for example if you use > > jhbuild to build just one application (for example `jhbuild > > build transmission`) and not the full desktop. The other > > solution is make all modules installing icons in > > $(prefix)/share/icons/hicolor depend on "hicolor-icon-theme" > > Maybe as ? I'm for , gtk+ don't strictly depends on hicolor ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
Le jeudi 06 novembre 2008 à 13:13 +0100, Vincent Untz a écrit : > Le samedi 01 novembre 2008, à 19:27 +0100, Philippe Rouquier a écrit : > > Hi, > > > > We'd be interested in having brasero integrated into the GNOME desktop. > > Please add brasero to the list at the top of > http://live.gnome.org/TwoPointTwentyfive/Desktop and also add it to > gnome-suites-2.26.modules (below the comment > and in the meta-gnome-proposed metamodule). > > Vincent > Done as well for brasero. Brasero seems to be in jhbuild but it's to be confirmed. Thanks, Philippe ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: update of jhbuild module dependencies
Luca Ferretti wrote: > A quick report Thanks. > * WebKit missing in "meta-gnome-proposed" ?? note that WebKit will > grab ~400 MB from git. > * libunique missing in "meta-gnome-proposed" We do not list proposed external dependencies in meta-gnome-proposed; unique and libproxy are already set in gnome-external-deps-2.26; WebKit should be added. > * a little mess with clutter stuff: we have "clutter" in > gnome-external-deps-2.26 (0.8.2 targz) and in gnome-2.26 (svn > trunk) and "clutter-0.8" (svn branch) as well as a lot of > "clutter-XXX-0.8": clutter 0.8.x is official external dep for > GNOME 2.24. Will we switch to 0.9/1.0 in 2.26? Emmanuele? I saw that, and I added "ask ebassi on #clutter" in my TODO list... > * a little request: could we force to build "hicolor-icon-theme" > before "gtk+"? This could be useful, for example if you use > jhbuild to build just one application (for example `jhbuild > build transmission`) and not the full desktop. The other > solution is make all modules installing icons in > $(prefix)/share/icons/hicolor depend on "hicolor-icon-theme" Maybe as ? > * maybe the same for intltool and gnome-common? I think modules using gnome-autogen.sh (from gnome-common) should just depend on gnome-common, it is not needed to fake dependencies here. And modules using AC_PROG_INTLTOOL or IT_PROG_INTLTOOL should list intltool in their builddeps. Checking for those should be straightforward; will do that tomorrow. Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: update of jhbuild module dependencies
Il giorno sab, 08/11/2008 alle 21.25 +0100, Frederic Peters ha scritto: > Hello all, > > Hopefully I didn't introduce any mistake but as I didn't get to do > a full rebuild in a clean environment, I can't tell for sure, so file > bugs if you encounter a missing dependency when building GNOME with > jhbuild. A quick report * devhelp trunk (used in gnome-suites-2.26) depends on WebKit, not mozilla * WebKit missing in "meta-gnome-proposed" ?? note that WebKit will grab ~400 MB from git. * libunique missing in "meta-gnome-proposed" * a little mess with clutter stuff: we have "clutter" in gnome-external-deps-2.26 (0.8.2 targz) and in gnome-2.26 (svn trunk) and "clutter-0.8" (svn branch) as well as a lot of "clutter-XXX-0.8": clutter 0.8.x is official external dep for GNOME 2.24. Will we switch to 0.9/1.0 in 2.26? Emmanuele? * a little request: could we force to build "hicolor-icon-theme" before "gtk+"? This could be useful, for example if you use jhbuild to build just one application (for example `jhbuild build transmission`) and not the full desktop. The other solution is make all modules installing icons in $(prefix)/share/icons/hicolor depend on "hicolor-icon-theme" * maybe the same for intltool and gnome-common? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
update of jhbuild module dependencies
Hello all, gnome-suites-2.26.modules | 188 1 file changed, 151 insertions(+), 37 deletions(-) I spent some time passing over modules, checking their dependencies against what was declared in jhbuild, removing libgnome/ui at places, adding libnotify as suggestion at others, and other similar changes. Hopefully I didn't introduce any mistake but as I didn't get to do a full rebuild in a clean environment, I can't tell for sure, so file bugs if you encounter a missing dependency when building GNOME with jhbuild. Thanks, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Update Python version to >= 2.5
2008/11/7 Luca Ferretti <[EMAIL PROTECTED]>: > Current version is 2.4.3[1] and I know a Python update was yet discussed > in past, but please also consider: > > * libproxy (suggested for 2.26) ask for python >= 2.5 > * gobject-introspection (needed by gnome-shell) ask for python >= >2.5 > * other modules I'm missing? > > I think this is the right time to update from 2.4 to 2.5 (or 2.6 > directly), or at least do it in `jhbuild bootstrap`. Sounds like a great idea. Is there any major distro left that does not ship Python 2.5? -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Thu, 2008-11-06 at 13:14 +0100, Vincent Untz wrote: > Le jeudi 23 octobre 2008, à 14:53 +0100, Bastien Nocera a écrit : > > Heya, > > > > I'd be interested in getting gnome-user-share into GNOME 2.26. > > Same comments as the ones I did for brasero :-) > > Please add gnome-user-share to the list at the top of > http://live.gnome.org/TwoPointTwentyfive/Desktop Done. > and also add it to > gnome-suites-2.26.modules (below the > comment > and in the meta-gnome-proposed metamodule). Me no usey jhbuild. Somebody else will have to get that working... Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposed external dependency: Mono.Addins
Howdy, Tomboy has depended on Mono.Addins >= 0.3 [1] for over a year now, but since it's not a blessed dependency in GNOME we've been forced to bundle a copy. For all the obvious reasons why this is a bad idea, we'd like to stop doing it. Mono.Addins is widely used in the Mono community by popular (extensible) apps like Banshee, F-Spot, Gnome Do, and MonoDevelop. It is packaged by all major distros. To quote the website, "Mono.Addins is a framework for creating extensible applications, and for creating libraries which extend those applications." Thanks, Sandy [1] http://mono-project.com/Mono.Addins ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: WebKit/GTK+
Il giorno sab, 08/11/2008 alle 00.11 +, Alp Toker ha scritto: > 2008/11/7 Willie Walker <[EMAIL PROTECTED]>: > One more thing -- action point 0: It's high time to unblock the GNOME > WebKit dependency situation. Good accessibility is central, but we > also have a reputation for stability and internationalisation in > GNOME. About non a11y-stuff in WebKit, you could also consider: * publish targz on ftp://ftp.gnome.org/pub/gnome/sources/ * send email with news to announce mailing list * put developer docs (API refs with gtk-doc and other, if any) on http://library.gnome.org (is the gtk-doc support still pending?) * provide a basic "test suite" for real world, i.e. build WebKit, go to a site/page/html, compare rendering (webkit vs gecko)[1], report it About l10n/i18n, what's the plan? How many strings will webkit mark as translatable? the inspector too? And how can translators provide PO file? In GNOME, translators can directly upload po files on svn, but I don't think this approach is good for webkit. Something like launchpad.net? Finally, could we have a little summary of changes between 1.0.1 release and current trunk, as well as missing features (a11y apart) needed for good web browsing experience (plain html rendering semms fine to me in devhelp and yelp)? While, of course, a lot of stuff should be implemented and managed in Epiphany (https, cookies, ...) [1] for example, there are some visual issues in Transmission bittorrent client web interface (bug #20157) or the javascript animation on jimmac homepage (no yet reported). > To achieve all three of these goals in time for release, we > need to stop putting out old tarballs from 2.24 and start making > development snapshots from trunk. Currently in jhbuild WebKit is grabbed from git mirror on debian, about 400 MiB on first fetch External deps should provided as released tarballs, to make distributors happy. But, nobody will say to not provide a new weekly release and use it. This is the way in the previous GNOME releases was managed gtk-vnc and swfdec-gnome deps... and will save a lot of space on my harddisk ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
