Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
Il giorno mer, 10/03/2010 alle 19.05 +0100, Frederic Crozat ha scritto: Well, I'm currently strugling with smoketesting GNOME 2.29.5 release and there are some tarballs no longer building because new G_SEAL deprecation were added in yesterday GTK+ 2.19.3 release and some modules were not fixed for this. A secondary reminder: please also note that due to recent deprecation of some GTK_WIDGET_* macros in GTK+, you'll have to use *new* functions (such as gtk_widget_get_realized or get_mapped) and then increase GTK_REQUIRED in configure.in to 2.19.7 too. Cheers, Luca ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
Le jeudi 11 mars 2010 à 17:50 -0500, Braden McDaniel a écrit : On 3/11/10 11:09 AM, Matthew Barnes wrote: I assume the GNOME_MAINTAINER_MODE_DEFINES macro is our preferred means of addressing this since it exists in gnome-common? It uses maintainer mode to determine whether to enable deprecation flags. AM_MAINTAINER_MODE is of debatable (and debated) value. If you are unaware of this, the Automake manual can fill you in. This was discussed a few days ago, and I wouldn’t call AM_MAINTAINER_MODE([enable]) debatable or controversial. Used this way, it has zero impact unless you pass a specific option. -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
On Wed, Mar 10, 2010 at 6:05 PM, Frederic Crozat fcro...@mandriva.comwrote: Le 12/01/2010 18:50, Frederic Crozat a écrit : Hi everyone, just a quick reminder about deprecation flags and tarball release : please avoid at all cost to hardcode deprecation flags in compilation flags, when a module is built from a tarball (it is ok to have such flags when building from gi checkout). Why, you may ask ? Well, I'm currently strugling with smoketesting GNOME 2.29.5 release and there are some tarballs no longer building because new G_SEAL deprecation were added in yesterday GTK+ 2.19.3 release and some modules were not fixed for this. Current guilty modules : - vte (bedhad is cooking a new release) - gnome-utils In a similar idea, try to avoid releasing tarballs which depends on other unreleased tarball module version. Since I'm the release team member taking care of 2.29.92 release, I'm going to rant again against modules which are hardcoding deprecation flags in their configure.in (or Makefile.am), even when building from tarballs. Please, avoid that, it is killing us, since many released modules are not building with latest gtk+ 2.19.7 (new deprecated added). If you want to use deprecation flags, check in configure.in if you are in a git checkout and enable them in that case, but do not enable them by default in tarballs. Current guilty modules, which needs a new release NOW (this is blocking GNOME 2.29.92 release): -gnome-python-desktop (doesn't build with latest totem-pl-parser, it seems) I am not aware of gnome-python-desktop 2.29.1 failing to build with newest totem-pl-parser. Just tried jhbuilding both, it works fine. -clutter-gtk -evince -gconf-editor -gucharmap -gnome-mag -gnome-terminal Thanks you for you attention. -- Frederic Crozat Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
Le 11/03/2010 14:50, Gustavo Carneiro a écrit : On Wed, Mar 10, 2010 at 6:05 PM, Frederic Crozat fcro...@mandriva.com mailto:fcro...@mandriva.com wrote: Le 12/01/2010 18:50, Frederic Crozat a écrit : Hi everyone, just a quick reminder about deprecation flags and tarball release : please avoid at all cost to hardcode deprecation flags in compilation flags, when a module is built from a tarball (it is ok to have such flags when building from gi checkout). Why, you may ask ? Well, I'm currently strugling with smoketesting GNOME 2.29.5 release and there are some tarballs no longer building because new G_SEAL deprecation were added in yesterday GTK+ 2.19.3 release and some modules were not fixed for this. Current guilty modules : - vte (bedhad is cooking a new release) - gnome-utils In a similar idea, try to avoid releasing tarballs which depends on other unreleased tarball module version. Since I'm the release team member taking care of 2.29.92 release, I'm going to rant again against modules which are hardcoding deprecation flags in their configure.in http://configure.in (or Makefile.am), even when building from tarballs. Please, avoid that, it is killing us, since many released modules are not building with latest gtk+ 2.19.7 (new deprecated added). If you want to use deprecation flags, check in configure.in http://configure.in if you are in a git checkout and enable them in that case, but do not enable them by default in tarballs. Current guilty modules, which needs a new release NOW (this is blocking GNOME 2.29.92 release): -gnome-python-desktop (doesn't build with latest totem-pl-parser, it seems) I am not aware of gnome-python-desktop 2.29.1 failing to build with newest totem-pl-parser. Just tried jhbuilding both, it works fine. Unfortunately, the totem CFLAGS doesn't contains gtk include headers, so it breaks when building plparser.c : plparser.override:8:21: error: gtk/gtk.h: No such file or directory configure.ac : PKG_CHECK_MODULES(TOTEM_PLPARSER, [totem-plparser = totem_required_version pygtk-2.0 = pygtk_required_version], should be : PKG_CHECK_MODULES(TOTEM_PLPARSER, [totem-plparser = totem_required_version pygtk-2.0 = pygtk_required_version gtk+-2.0 ], (sorry for not opening a bug report, I thought it was related to deprecation) -- Frederic Crozat Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
On Thu, Mar 11, 2010 at 3:00 PM, Frederic Crozat fcro...@mandriva.comwrote: Le 11/03/2010 14:50, Gustavo Carneiro a écrit : On Wed, Mar 10, 2010 at 6:05 PM, Frederic Crozat fcro...@mandriva.com mailto:fcro...@mandriva.com wrote: Le 12/01/2010 18:50, Frederic Crozat a écrit : Hi everyone, just a quick reminder about deprecation flags and tarball release : please avoid at all cost to hardcode deprecation flags in compilation flags, when a module is built from a tarball (it is ok to have such flags when building from gi checkout). Why, you may ask ? Well, I'm currently strugling with smoketesting GNOME 2.29.5 release and there are some tarballs no longer building because new G_SEAL deprecation were added in yesterday GTK+ 2.19.3 release and some modules were not fixed for this. Current guilty modules : - vte (bedhad is cooking a new release) - gnome-utils In a similar idea, try to avoid releasing tarballs which depends on other unreleased tarball module version. Since I'm the release team member taking care of 2.29.92 release, I'm going to rant again against modules which are hardcoding deprecation flags in their configure.in http://configure.in (or Makefile.am), even when building from tarballs. Please, avoid that, it is killing us, since many released modules are not building with latest gtk+ 2.19.7 (new deprecated added). If you want to use deprecation flags, check in configure.in http://configure.in if you are in a git checkout and enable them in that case, but do not enable them by default in tarballs. Current guilty modules, which needs a new release NOW (this is blocking GNOME 2.29.92 release): -gnome-python-desktop (doesn't build with latest totem-pl-parser, it seems) I am not aware of gnome-python-desktop 2.29.1 failing to build with newest totem-pl-parser. Just tried jhbuilding both, it works fine. Unfortunately, the totem CFLAGS doesn't contains gtk include headers, so it breaks when building plparser.c : plparser.override:8:21: error: gtk/gtk.h: No such file or directory configure.ac : PKG_CHECK_MODULES(TOTEM_PLPARSER, [totem-plparser = totem_required_version pygtk-2.0 = pygtk_required_version], should be : PKG_CHECK_MODULES(TOTEM_PLPARSER, [totem-plparser = totem_required_version pygtk-2.0 = pygtk_required_version gtk+-2.0 ], You are right that it does not build. I was convinced that 2.29.1 had the latest code in git, but I was mistaken. I just released 2.29.92 which should fix that build problem. Sorry for the delay. (sorry for not opening a bug report, I thought it was related to deprecation) -- Frederic Crozat Mandriva -- Gustavo J. A. M. Carneiro INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
On Wed, 2010-03-10 at 19:05 +0100, Frederic Crozat wrote: Since I'm the release team member taking care of 2.29.92 release, I'm going to rant again against modules which are hardcoding deprecation flags in their configure.in (or Makefile.am), even when building from tarballs. Please, avoid that, it is killing us, since many released modules are not building with latest gtk+ 2.19.7 (new deprecated added). If you want to use deprecation flags, check in configure.in if you are in a git checkout and enable them in that case, but do not enable them by default in tarballs. I assume the GNOME_MAINTAINER_MODE_DEFINES macro is our preferred means of addressing this since it exists in gnome-common? It uses maintainer mode to determine whether to enable deprecation flags. Matthew Barnes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
On 3/11/10 11:09 AM, Matthew Barnes wrote: On Wed, 2010-03-10 at 19:05 +0100, Frederic Crozat wrote: Since I'm the release team member taking care of 2.29.92 release, I'm going to rant again against modules which are hardcoding deprecation flags in their configure.in (or Makefile.am), even when building from tarballs. Please, avoid that, it is killing us, since many released modules are not building with latest gtk+ 2.19.7 (new deprecated added). If you want to use deprecation flags, check in configure.in if you are in a git checkout and enable them in that case, but do not enable them by default in tarballs. I assume the GNOME_MAINTAINER_MODE_DEFINES macro is our preferred means of addressing this since it exists in gnome-common? It uses maintainer mode to determine whether to enable deprecation flags. AM_MAINTAINER_MODE is of debatable (and debated) value. If you are unaware of this, the Automake manual can fill you in. The question of whether one wants deprecation flags has pretty much nothing to do with what AM_MAINTAINER_MODE does; and it also seems unwise to attach this functionality to something as controversial as AM_MAINTAINER_MODE. -- Braden McDaniel bra...@endoframe.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
Le 12/01/2010 18:50, Frederic Crozat a écrit : Hi everyone, just a quick reminder about deprecation flags and tarball release : please avoid at all cost to hardcode deprecation flags in compilation flags, when a module is built from a tarball (it is ok to have such flags when building from gi checkout). Why, you may ask ? Well, I'm currently strugling with smoketesting GNOME 2.29.5 release and there are some tarballs no longer building because new G_SEAL deprecation were added in yesterday GTK+ 2.19.3 release and some modules were not fixed for this. Current guilty modules : - vte (bedhad is cooking a new release) - gnome-utils In a similar idea, try to avoid releasing tarballs which depends on other unreleased tarball module version. Since I'm the release team member taking care of 2.29.92 release, I'm going to rant again against modules which are hardcoding deprecation flags in their configure.in (or Makefile.am), even when building from tarballs. Please, avoid that, it is killing us, since many released modules are not building with latest gtk+ 2.19.7 (new deprecated added). If you want to use deprecation flags, check in configure.in if you are in a git checkout and enable them in that case, but do not enable them by default in tarballs. Current guilty modules, which needs a new release NOW (this is blocking GNOME 2.29.92 release): -gnome-python-desktop (doesn't build with latest totem-pl-parser, it seems) -clutter-gtk -evince -gconf-editor -gucharmap -gnome-mag -gnome-terminal Thanks you for you attention. -- Frederic Crozat Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
On 10/03/10 19:05, Frederic Crozat wrote: Since I'm the release team member taking care of 2.29.92 release, I'm going to rant again against modules which are hardcoding deprecation flags in their configure.in (or Makefile.am), even when building from tarballs. Please, avoid that, it is killing us, since many released modules are not building with latest gtk+ 2.19.7 (new deprecated added). If you want to use deprecation flags, check in configure.in if you are in a git checkout and enable them in that case, but do not enable them by default in tarballs. This is also harmful to distributors as it means some packages will start to FTBFS when updating a different one (e.g. because it adds new deprecations). So full ACK. Cheers, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder : do NOT hardcode deprecation flags in tarball / new tarballs NEEDED
On Wed, 2010-03-10 at 19:05 +0100, Frederic Crozat wrote: Since I'm the release team member taking care of 2.29.92 release, I'm going to rant again against modules which are hardcoding deprecation flags in their configure.in (or Makefile.am), even when building from tarballs. Please, avoid that, it is killing us, since many released modules are not building with latest gtk+ 2.19.7 (new deprecated added). If you want to use deprecation flags, check in configure.in if you are in a git checkout and enable them in that case, but do not enable them by default in tarballs. In the gtkmm world, thanks to Daniel Elstner, we have long had a configure.ac macro that uses the autotools idea of maintainer-mode, so we can use certain build options when using autogen.sh or when doing distcheck, without affecting tarballs builds. The latest version is the MM_ARG_ENABLE_WARNINGS() macro, which is used in this example project: http://git.gnome.org/browse/mm-common/tree/skeletonmm/configure.ac#n55 It has some documentation here: http://git.gnome.org/browse/mm-common/tree/macros/mm-warnings.m4#n35 In Glom I use the older DK_ARG_ENABLE_WARNINGS() macro and you can see where I've mentioned deprecations: http://git.gnome.org/browse/glom/tree/configure.ac#n189 I've seen some talk of putting this in gnome-common, which seems like a good idea. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
