releasing 1.9 soon...

[David Nečas (Yeti)-2]

Following the gtk-devel discussion, if we want $SUBJ, things
concerning srcdir != builddir can be postponed IMO (it has
never worked properly anyway), and only the following should
be dealt with:

  http://bugzilla.gnome.org/show_bug.cgi?id=338068
  enable template-free build
  I'll look at the xml cleaning.

  http://bugzilla.gnome.org/show_bug.cgi?id=433338
  Doesn't rebuild the documentation when the .types file changes
  As suggesed, I would close as WONTFIX.

  http://bugzilla.gnome.org/show_bug.cgi?id=466963
  1.8 makes make distcheck fail
  I would close as NOTABUG, but this is politics...

  http://bugzilla.gnome.org/show_bug.cgi?id=471014
  G_CONST_RETURN * G_CONST_RETURN * function not picked up
  Simple and a patch is available.

That and the misguided --online option still present in
fixxref.

Then we should give it a good testing.

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

Hi,

David Nečas (Yeti) wrote:
> Following the gtk-devel discussion, if we want $SUBJ, things
> concerning srcdir != builddir can be postponed IMO (it has
> never worked properly anyway), and only the following should
> be dealt with:
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=338068
>   enable template-free build
>   I'll look at the xml cleaning.
>
Commented & will apply real soon.
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=433338
>   Doesn't rebuild the documentation when the .types file changes
>   As suggesed, I would close as WONTFIX.
I put a comment about a compromise there. Need to give it a try to see if it
will work.
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=466963
>   1.8 makes make distcheck fail
>   I would close as NOTABUG, but this is politics...
Agree & done.
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=471014
>   G_CONST_RETURN * G_CONST_RETURN * function not picked up
>   Simple and a patch is available.
Will try it.
>
> That and the misguided --online option still present in
> fixxref.
Ok. I try to find some time to rip it out.

>
> Then we should give it a good testing.
>
Has anyone reading this list tried it? Any big problems (that not have been
there for ages anyway)?

Stefan

>
> Yeti
>
> --
> http://gwyddion.net/
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-doc-list

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

Hi again,

do you have any opinion on these:

http://bugzilla.gnome.org/show_bug.cgi?id=467773
default master doc should have proper extension
-> apply?

http://bugzilla.gnome.org/show_bug.cgi?id=448879
Use a footer when generating HTML documentation
-> I don't adding a footer so much

http://bugzilla.gnome.org/show_bug.cgi?id=338342
pkg-config check in gtk-doc.m4 isn't versionned
-> closing?

Stefan

David Nečas (Yeti) wrote:

> Following the gtk-devel discussion, if we want $SUBJ, things
> concerning srcdir != builddir can be postponed IMO (it has
> never worked properly anyway), and only the following should
> be dealt with:
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=338068
>   enable template-free build
>   I'll look at the xml cleaning.
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=433338
>   Doesn't rebuild the documentation when the .types file changes
>   As suggesed, I would close as WONTFIX.
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=466963
>   1.8 makes make distcheck fail
>   I would close as NOTABUG, but this is politics...
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=471014
>   G_CONST_RETURN * G_CONST_RETURN * function not picked up
>   Simple and a patch is available.
>
> That and the misguided --online option still present in
> fixxref.
>
> Then we should give it a good testing.
>
> Yeti
>
> --
> http://gwyddion.net/
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-doc-list

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Mon, Sep 10, 2007 at 10:14:24PM +0300, Stefan Kost wrote:
> http://bugzilla.gnome.org/show_bug.cgi?id=448879
> Use a footer when generating HTML documentation
> -> I don't adding a footer so much

I don't have any opinion.  I view documentation with dillo,
therefore it has been always working for me...

Design-wise, large spacer at the bottom is an issue mainly
if it's followed by a footer.

> http://bugzilla.gnome.org/show_bug.cgi?id=338342
> pkg-config check in gtk-doc.m4 isn't versionned
> -> closing?

Dunno, shouldn't we check for pkg-config >= 0.19 in
gtk-doc.m4 as suggested?  What

  # Make sure we have pkg-config >= 0.19, so installing in $(datadir) is OK.

in gtk-doc's configure.in tries to achieve?

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Matthias Clasen-2]

On 9/8/07, David Nečas (Yeti) <yeti@...> wrote:
>
> Following the gtk-devel discussion, if we want $SUBJ, things
> concerning srcdir != builddir can be postponed IMO (it has
> never worked properly anyway), and only the following should
> be dealt with:
>

Here is one problem I found today while trying to do a gtk 2.12.0 release with
svn gtk-doc:

[...]

mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/tmpl
mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/xml
mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/html
cp ./tmpl/*.sgml ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/tmpl
cp ./xml/*.xml ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/xml
cp ./html/* ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/html
case "x --source-dir=../../../contrib/gdk-pixbuf-xlib
--deprecated-guards="GDK_PIXBUF_ENABLE_BROKEN|GDK_PIXBUF_DISABLE_DEPRECATED"
" in \
          *' --rebuild-types '*) ;; \
          *) cp ./gdk-pixbuf.types
../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/;; \
        esac
/bin/sh: -c: line 0: syntax error near unexpected token `|'
/bin/sh: -c: line 0: `case "x
--source-dir=../../../contrib/gdk-pixbuf-xlib
--deprecated-guards="GDK_PIXBUF_ENABLE_BROKEN|GDK_PIXBUF_DISABLE_DEPRECATED"
" in \'
make[4]: *** [dist-hook] Error 2


This comes from the following part of gtk-doc.make:

distclean-local:
        cd $(srcdir) && \
          rm -rf xml $(REPORT_FILES) \
                 $(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt
        case "x $(SCAN_OPTIONS) " in \
          *' --rebuild-types '*) rm -f $(srcdir)/$(DOC_MODULE).types;; \
        esac
        case "x $(SCAN_OPTIONS) " in \
          *' --rebuild-sections '*) rm -f
$(srcdir)/$(DOC_MODULE)-sections.txt;; \
        esac


Any chance to make that work with existing uses of gtk-doc before
releasing 1.9 ?
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Thu, Sep 13, 2007 at 07:35:11PM -0400, Matthias Clasen wrote:

>
> Here is one problem I found today while trying to do a gtk 2.12.0 release with
> svn gtk-doc:
> ...
>
> This comes from the following part of gtk-doc.make:
>
> distclean-local:
>         cd $(srcdir) && \
>           rm -rf xml $(REPORT_FILES) \
>                  $(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt
>         case "x $(SCAN_OPTIONS) " in \
>           *' --rebuild-types '*) rm -f $(srcdir)/$(DOC_MODULE).types;; \
>         esac
>         case "x $(SCAN_OPTIONS) " in \
>           *' --rebuild-sections '*) rm -f
> $(srcdir)/$(DOC_MODULE)-sections.txt;; \
>         esac

Ah, and I thought how clever I was and instead I made the
textbook make expansion mistake...

> Any chance to make that work with existing uses of gtk-doc before
> releasing 1.9 ?

Of course, except that all methods I can imagine to check
the content of a make variable in a rule scriptlet are
non-portable or break in some cases.

The only method that would in the worst case just fail to
see the option seems to be extracting the value of the
variable from Makefile with sed.  And that's rather silly.

Well, it's always possible to distribute the files even if
they are generated and useless.

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Fri, Sep 14, 2007 at 01:55:42AM +0200, David Nečas (Yeti) wrote:
> Well, it's always possible to distribute the files even if
> they are generated and useless.

Stefan, please apply the attached patch.  I can't see any
reliable method to check whether types and sections are
built files that would be less ugly than distributing them
even if they are built.

Yeti

--
http://gwyddion.net/

Index: gtk-doc.make
===================================================================
--- gtk-doc.make (revision 490)
+++ gtk-doc.make (working copy)
@@ -123,12 +123,6 @@
  cd $(srcdir) && \
   rm -rf xml $(REPORT_FILES) \
          $(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt
- case "x $(SCAN_OPTIONS) " in \
-  *' --rebuild-types '*) rm -f $(srcdir)/$(DOC_MODULE).types;; \
- esac
- case "x $(SCAN_OPTIONS) " in \
-  *' --rebuild-sections '*) rm -f $(srcdir)/$(DOC_MODULE)-sections.txt;; \
- esac
 
 maintainer-clean-local: clean
  cd $(srcdir) && rm -rf xml html
@@ -169,14 +163,8 @@
  -cp $(srcdir)/tmpl/*.sgml $(distdir)/tmpl
  -cp $(srcdir)/xml/*.xml $(distdir)/xml
  cp $(srcdir)/html/* $(distdir)/html
- case "x $(SCAN_OPTIONS) " in \
-  *' --rebuild-types '*) ;; \
-  *) cp $(srcdir)/$(DOC_MODULE).types $(distdir)/;; \
- esac
- case "x $(SCAN_OPTIONS) " in \
-  *' --rebuild-sections '*) ;; \
-  *) cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/;; \
- esac
+ cp $(srcdir)/$(DOC_MODULE).types $(distdir)/
+ cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/
  -gtkdoc-rebase --online --relative --html-dir=$(distdir)/html
 
 .PHONY : dist-hook-local docs
Index: gtk-doc.notmpl.make
===================================================================
--- gtk-doc.notmpl.make (revision 490)
+++ gtk-doc.notmpl.make (working copy)
@@ -108,12 +108,6 @@
  cd $(srcdir) && \
   rm -rf xml $(REPORT_FILES) \
          $(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt
- case "x $(SCAN_OPTIONS) " in \
-  *' --rebuild-types '*) rm -f $(srcdir)/$(DOC_MODULE).types;; \
- esac
- case "x $(SCAN_OPTIONS) " in \
-  *' --rebuild-sections '*) rm -f $(srcdir)/$(DOC_MODULE)-sections.txt;; \
- esac
 
 maintainer-clean-local: clean
  cd $(srcdir) && rm -rf html
@@ -150,14 +144,8 @@
 dist-hook: dist-check-gtkdoc dist-hook-local
  mkdir $(distdir)/html
  cp $(srcdir)/html/* $(distdir)/html
- case "x $(SCAN_OPTIONS) " in \
-  *' --rebuild-types '*) ;; \
-  *) cp $(srcdir)/$(DOC_MODULE).types $(distdir)/;; \
- esac
- case "x $(SCAN_OPTIONS) " in \
-  *' --rebuild-sections '*) ;; \
-  *) cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/;; \
- esac
+ cp $(srcdir)/$(DOC_MODULE).types $(distdir)/
+ cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/
  -gtkdoc-rebase --online --relative --html-dir=$(distdir)/html
 
 .PHONY : dist-hook-local docs

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

hi,

allthough ugly, adding a gtkdoc-disthelper script that gets invoked on
dist-hook:
   gtkdoc-disthelper $(SCAN_OPTIONS)
distclean-local:
   gtkdoc-disthelper $(SCAN_OPTIONS)
could help.

Stefan

Quoting "David Nečas (Yeti)" <yeti@...>:

> On Fri, Sep 14, 2007 at 01:55:42AM +0200, David Nečas (Yeti) wrote:
>> Well, it's always possible to distribute the files even if
>> they are generated and useless.
>
> Stefan, please apply the attached patch.  I can't see any
> reliable method to check whether types and sections are
> built files that would be less ugly than distributing them
> even if they are built.
>
> Yeti
>
> --
> http://gwyddion.net/
>

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

hi,

actually, I think its only the quoting that needs a change:
-case "x $(SCAN_OPTIONS) " in \
+case 'x $(SCAN_OPTIONS) ' in \

then it works for me

Stefan

Quoting Matthias Clasen <matthias.clasen@...>:

> On 9/8/07, David Nečas (Yeti) <yeti@...> wrote:
>>
>> Following the gtk-devel discussion, if we want $SUBJ, things
>> concerning srcdir != builddir can be postponed IMO (it has
>> never worked properly anyway), and only the following should
>> be dealt with:
>>
>
> Here is one problem I found today while trying to do a gtk 2.12.0  
> release with
> svn gtk-doc:
>
> [...]
>
> mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/tmpl
> mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/xml
> mkdir ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/html
> cp ./tmpl/*.sgml ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/tmpl
> cp ./xml/*.xml ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/xml
> cp ./html/* ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/html
> case "x --source-dir=../../../contrib/gdk-pixbuf-xlib
> --deprecated-guards="GDK_PIXBUF_ENABLE_BROKEN|GDK_PIXBUF_DISABLE_DEPRECATED"
> " in \
>           *' --rebuild-types '*) ;; \
>           *) cp ./gdk-pixbuf.types
> ../../../gtk+-2.12.0/docs/reference/gdk-pixbuf/;; \
>         esac
> /bin/sh: -c: line 0: syntax error near unexpected token `|'
> /bin/sh: -c: line 0: `case "x
> --source-dir=../../../contrib/gdk-pixbuf-xlib
> --deprecated-guards="GDK_PIXBUF_ENABLE_BROKEN|GDK_PIXBUF_DISABLE_DEPRECATED"
> " in \'
> make[4]: *** [dist-hook] Error 2
>
>
> This comes from the following part of gtk-doc.make:
>
> distclean-local:
>         cd $(srcdir) && \
>           rm -rf xml $(REPORT_FILES) \
>                  $(DOC_MODULE)-decl-list.txt $(DOC_MODULE)-decl.txt
>         case "x $(SCAN_OPTIONS) " in \
>           *' --rebuild-types '*) rm -f $(srcdir)/$(DOC_MODULE).types;; \
>         esac
>         case "x $(SCAN_OPTIONS) " in \
>           *' --rebuild-sections '*) rm -f
> $(srcdir)/$(DOC_MODULE)-sections.txt;; \
>         esac
>
>
> Any chance to make that work with existing uses of gtk-doc before
> releasing 1.9 ?
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-doc-list
>

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Mon, Sep 17, 2007 at 05:00:28PM +0200, Stefan Kost wrote:
> actually, I think its only the quoting that needs a change:
> -case "x $(SCAN_OPTIONS) " in \
> +case 'x $(SCAN_OPTIONS) ' in \
>
> then it works for me

No, it does not.  It only means you do not have anything
quoted with single quotes in $(SCAN_OPTIONS).

The basic trouble is that make does not care about the
underlying syntax, it just substitutes text, therefore no
quoting can work.

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Mon, Sep 17, 2007 at 04:47:39PM +0200, Stefan Kost wrote:
> allthough ugly, adding a gtkdoc-disthelper script that gets invoked on
> dist-hook:
>   gtkdoc-disthelper $(SCAN_OPTIONS)
> distclean-local:
>   gtkdoc-disthelper $(SCAN_OPTIONS)
> could help.

This does not work either, see for instance gtk-doc's own
test suite which sets the variable

  SCAN_OPTIONS=--deprecated-guards="GTKDOC_TESTER_DISABLE_DEPRECATED" 2>&1 | tee gtkdoc-scan.log

I.e., make distclean would create file gtk-scan.log.

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Mon, Sep 17, 2007 at 06:58:21PM +0200, David Nečas (Yeti) wrote:
> This does not work either...

A method that has a good chance to work:

  Do not try to parse SCAN_OPTIONS and let the user add the
  files to DISTCLEANFILES (gtk-doc.make does not use it
  internally) manually.

  Happily copy everything to $(distdir) in the dist hook and
  then do something like

    cd $(distdir) && rm -f $(DISTCLEANFILES)

  in the dist hook (putting the files in DISTCLEANFILES
  already takes care of cleaning them in distclean).

  Although DISTCLEANFILES can in principle contain all kinds
  of shell code too, it is quite unlikely to contain
  anything fragile because people cannot be sure precisely
  how automake uses it.

An advantage of this approach is its universality: The user
does not want to distribute some files -- any files -- so he
adds them to DISTCLEANFILES.  And that's all, they are
correctly dist-cleaned and excluded from distribution.

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

Hi,

regarding gtkdoc-fixxref.pl should I just revert that patch:
http://bugzilla.gnome.org/attachment.cgi?id=91852
I've did a dry-run and it still applies.

Regarding your proposal below - sounds good. So this means we merely document
that users can use DISTCLEANFILES in the userdocs and in the gtkdoc.mak. Can you
suppy a new patch?

Ich checked out the webpage and will start to prepare release notes.

Stefan

David Nečas (Yeti) wrote:

> On Mon, Sep 17, 2007 at 06:58:21PM +0200, David Nečas (Yeti) wrote:
>> This does not work either...
>
> A method that has a good chance to work:
>
>   Do not try to parse SCAN_OPTIONS and let the user add the
>   files to DISTCLEANFILES (gtk-doc.make does not use it
>   internally) manually.
>
>   Happily copy everything to $(distdir) in the dist hook and
>   then do something like
>
>     cd $(distdir) && rm -f $(DISTCLEANFILES)
>
>   in the dist hook (putting the files in DISTCLEANFILES
>   already takes care of cleaning them in distclean).
>
>   Although DISTCLEANFILES can in principle contain all kinds
>   of shell code too, it is quite unlikely to contain
>   anything fragile because people cannot be sure precisely
>   how automake uses it.
>
> An advantage of this approach is its universality: The user
> does not want to distribute some files -- any files -- so he
> adds them to DISTCLEANFILES.  And that's all, they are
> correctly dist-cleaned and excluded from distribution.
>
> Yeti
>
> --
> http://gwyddion.net/
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-doc-list

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Wed, Sep 19, 2007 at 08:54:55PM +0300, Stefan Kost wrote:
> regarding gtkdoc-fixxref.pl should I just revert that patch:
> http://bugzilla.gnome.org/attachment.cgi?id=91852

It seems, I don't recall any related change that would have
to be reverted, the feature has never been actually used.

> Regarding your proposal below - sounds good. So this means we merely document
> that users can use DISTCLEANFILES in the userdocs and in the gtkdoc.mak. Can you
> suppy a new patch?

Of course.

> Ich checked out the webpage and will start to prepare release notes.

IMO we should test build of documentation of Gnome 2.20
versions of everything at

  http://library.gnome.org/devel/references

before releasing a new gtk-doc.  People of course built
their API documentation, but not necessarily with what we
are going to release and not looking for the same kind of
issues we would.

Yeti

--
http://gwyddion.net/

Index: gtk-doc.make
===================================================================
--- gtk-doc.make (revision 493)
+++ gtk-doc.make (working copy)
@@ -165,6 +165,7 @@
  cp $(srcdir)/html/* $(distdir)/html
  cp $(srcdir)/$(DOC_MODULE).types $(distdir)/
  cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/
+ cd $(distdir) && rm -f $(DISTCLEANFILES)
  -gtkdoc-rebase --online --relative --html-dir=$(distdir)/html
 
 .PHONY : dist-hook-local docs
Index: gtk-doc.notmpl.make
===================================================================
--- gtk-doc.notmpl.make (revision 493)
+++ gtk-doc.notmpl.make (working copy)
@@ -146,6 +146,7 @@
  cp $(srcdir)/html/* $(distdir)/html
  cp $(srcdir)/$(DOC_MODULE).types $(distdir)/
  cp $(srcdir)/$(DOC_MODULE)-sections.txt $(distdir)/
+ cd $(distdir) && rm -f $(DISTCLEANFILES)
  -gtkdoc-rebase --online --relative --html-dir=$(distdir)/html
 
 .PHONY : dist-hook-local docs

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

hi,

I hope now all patches have been applied. I also added a target milestone to the
bug we fixed in this cycle. This allow me to pull the buglist out of bugzilla
fro the release notes - sorry for the resulting spam. I have also created 1.10
target milestone, so please us that when closing bugs after the release.

Next I'll try to see if the build.gnome.org could run build with snv-trunk
version of gtk-doc. If I have time I'll try a jhbuild of gnome-2.20 locally too.

Stefan

David Nečas (Yeti) wrote:

> Following the gtk-devel discussion, if we want $SUBJ, things
> concerning srcdir != builddir can be postponed IMO (it has
> never worked properly anyway), and only the following should
> be dealt with:
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=338068
>   enable template-free build
>   I'll look at the xml cleaning.
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=433338
>   Doesn't rebuild the documentation when the .types file changes
>   As suggesed, I would close as WONTFIX.
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=466963
>   1.8 makes make distcheck fail
>   I would close as NOTABUG, but this is politics...
>
>   http://bugzilla.gnome.org/show_bug.cgi?id=471014
>   G_CONST_RETURN * G_CONST_RETURN * function not picked up
>   Simple and a patch is available.
>
> That and the misguided --online option still present in
> fixxref.
>
> Then we should give it a good testing.
>
> Yeti
>
> --
> http://gwyddion.net/
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-doc-list

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Sat, Sep 22, 2007 at 11:09:45PM +0300, Stefan Kost wrote:
>
> I hope now all patches have been applied. I also added a target milestone to the
> bug we fixed in this cycle.

Please don't.  Bugzilla Target Milestone field is intended
for open bugs -- to track what to get done in a particular
version, timeframe, ...  Generally, it's a classification of
when in the future the issue is expected to be resolved.

(The stricter Gnome Target Milestone means that Gnome X.Y
cannot be released until all open bugs with X.Y milestone
are fixed.)

> This allow me to pull the buglist out of bugzilla
> fro the release notes - sorry for the resulting spam.

The list is incomplete anyway.  What about 322035, 383456,
445596, 450338, 465365, 466559?

If you want to know bugs fixed since the last gtk-doc
release, just ask bugzilla for it.

> I have also created 1.10
> target milestone, so please us that when closing bugs after the release.

While 1.10 target milestone is a good idea, I'm going to
mark bugs that should be fixed in 1.10 with it (e.g. the
postponed VPATH stuff) because this is what this flag means.

> Next I'll try to see if the build.gnome.org could run build with snv-trunk
> version of gtk-doc. If I have time I'll try a jhbuild of gnome-2.20 locally too.

Considering interesting error messages vary wildly (from perl
complaints such as `Use of uninitialized value...' to various
WARNINGs to xsltproc messages), how we find them in the
flood?

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

Hi,

David Nečas (Yeti) wrote:

> On Sat, Sep 22, 2007 at 11:09:45PM +0300, Stefan Kost wrote:
>> I hope now all patches have been applied. I also added a target milestone to the
>> bug we fixed in this cycle.
>
> Please don't.  Bugzilla Target Milestone field is intended
> for open bugs -- to track what to get done in a particular
> version, timeframe, ...  Generally, it's a classification of
> when in the future the issue is expected to be resolved.
>
> (The stricter Gnome Target Milestone means that Gnome X.Y
> cannot be released until all open bugs with X.Y milestone
> are fixed.)

Well then our understanding differs here. If a bug is closed as a reporter I
would like to know which release will have the fix. In the case of libraries I
could e.g. add a configure check for that version and disable a workaround if
the user has a recent enough version.

>
>> This allow me to pull the buglist out of bugzilla
>> fro the release notes - sorry for the resulting spam.
>
> The list is incomplete anyway.  What about 322035, 383456,
> 445596, 450338, 465365, 466559?
>
> If you want to know bugs fixed since the last gtk-doc
> release, just ask bugzilla for it.
>

Exactly, therefore I use the field.

>
>> I have also created 1.10
>> target milestone, so please us that when closing bugs after the release.
>
> While 1.10 target milestone is a good idea, I'm going to
> mark bugs that should be fixed in 1.10 with it (e.g. the
> postponed VPATH stuff) because this is what this flag means.
>
How will the user then know that it actaully happend. Once we release 1.10 one
has to make a query to bugzilla to get all open bug with that target milestone
and either postpone the release or move that target-milestone to 1.11.

>
>> Next I'll try to see if the build.gnome.org could run build with snv-trunk
>> version of gtk-doc. If I have time I'll try a jhbuild of gnome-2.20 locally too.
>
> Considering interesting error messages vary wildly (from perl
> complaints such as `Use of uninitialized value...' to various
> WARNINGs to xsltproc messages), how we find them in the
> flood?
>
I am open to ideas here. Its more a sanity check that ensure that now build
aborts etc.

Stefan

> Yeti
>
> --
> http://gwyddion.net/
> _______________________________________________
> gtk-doc-list mailing list
> gtk-doc-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-doc-list

_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[David Nečas (Yeti)-2]

On Sun, Sep 23, 2007 at 02:41:00PM +0300, Stefan Kost wrote:
>
> Well then our understanding differs here. If a bug is closed as a reporter I
> would like to know which release will have the fix. In the case of libraries I
> could e.g. add a configure check for that version and disable a workaround if
> the user has a recent enough version.

This is not about understanding, this is about misuse.
However worthy your goal might be, misuse of bugzilla fields
should not be the solution.

> > The list is incomplete anyway.  What about 322035, 383456,
> > 445596, 450338, 465365, 466559?
> >
> > If you want to know bugs fixed since the last gtk-doc
> > release, just ask bugzilla for it.
> >
> Exactly, therefore I use the field.

And my list is an illustration it does not work[*].  These
bugs were fixed by 1.9 byt they are not marked with 1.9
target milestone -- yet I easily found them by asking
bugzilla.

Exporting both bug lists to CSV and running diff on them
would reveal the complete set of fixed bugs that cannot be
found by looking for target milestone 1.9.

[*] Of course, you can run the proper query and then use the
mass bug changer to add a milestone to each in the list --
but what's the point when you can use the query?

> How will the user then know that it actaully happend. Once we release 1.10 one
> has to make a query to bugzilla to get all open bug with that target milestone
> and either postpone the release or move that target-milestone to 1.11.

At the moment we release 1.10 there should be no open bugs
with target milestone 1.10.

I'm not sure who `one' is in your description -- target
milestone is a developers' tool to keep track of issues that
should/must be resolved in a particular version or time
frame.

*Before* we (developers) release 1.10 we should deal with
all issues with target milestone 1.10: either resolve them
or decide to postpone them and change the target milestone.

> > Considering interesting error messages vary wildly (from perl
> > complaints such as `Use of uninitialized value...' to various
> > WARNINGs to xsltproc messages), how we find them in the
> > flood?
> >
> I am open to ideas here. Its more a sanity check that ensure that now build
> aborts etc.

If I knew how to find the start and end of documentation
build in the logs reliably, I'd just filter out everything
known to be harmless (Writing foo for refentry(bar)..., ID
recommended on..., gtk-doc: Running baz..., make:
Leaving/Entering directory ..., \-continued blocks that
looks like our commands, ...) and look at what remained.

Perhaps we can assume there is no interesting message before
`gtk-doc: Scanning header files' and that `touch
html-build.stamp' is the last thing printed, but it's not
exactly reliable.

Well, I don't even know how to get the actual logs from
build.gnome.org.  Moreover it seems most interestring builds
started failing on 16 September due to some infrastructure
change.

Yeti

--
http://gwyddion.net/
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

Hi,

David Nečas (Yeti) wrote:

> On Sun, Sep 23, 2007 at 02:41:00PM +0300, Stefan Kost wrote:
>> Well then our understanding differs here. If a bug is closed as a reporter I
>> would like to know which release will have the fix. In the case of libraries I
>> could e.g. add a configure check for that version and disable a workaround if
>> the user has a recent enough version.
>
> This is not about understanding, this is about misuse.
> However worthy your goal might be, misuse of bugzilla fields
> should not be the solution.
>
>>> The list is incomplete anyway.  What about 322035, 383456,
>>> 445596, 450338, 465365, 466559?
>>>
>>> If you want to know bugs fixed since the last gtk-doc
>>> release, just ask bugzilla for it.
>>>
>> Exactly, therefore I use the field.
>
> And my list is an illustration it does not work[*].  These
> bugs were fixed by 1.9 byt they are not marked with 1.9
> target milestone -- yet I easily found them by asking
> bugzilla.
>

I basicylly grepped the "Fixes #\d+" comments from the changelog. Maybe a query
by date in bugzilla would have work too. Is that what you have done?
Anyway I will now mark the missing one too to have a full list for the release
notes. In the future we shall use this as you said - to schedule bugs.

<snip>

>>> Considering interesting error messages vary wildly (from perl
>>> complaints such as `Use of uninitialized value...' to various
>>> WARNINGs to xsltproc messages), how we find them in the
>>> flood?
>>>
>> I am open to ideas here. Its more a sanity check that ensure that now build
>> aborts etc.
>
> If I knew how to find the start and end of documentation
> build in the logs reliably, I'd just filter out everything
> known to be harmless (Writing foo for refentry(bar)..., ID
> recommended on..., gtk-doc: Running baz..., make:
> Leaving/Entering directory ..., \-continued blocks that
> looks like our commands, ...) and look at what remained.
>
> Perhaps we can assume there is no interesting message before
> `gtk-doc: Scanning header files' and that `touch
> html-build.stamp' is the last thing printed, but it's not
> exactly reliable.
>
> Well, I don't even know how to get the actual logs from
> build.gnome.org.  Moreover it seems most interestring builds
> started failing on 16 September due to some infrastructure
> change.

I'll see if I run find some time for yhbuild.

Stefan
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list

[Stefan Kost]

Hi again,

I think it looks mostly okay now. Still have some trouble with getting make
distcheck to work though.

I also run a full jhbuild and have lots of gtk-doc books generated. So at least
it does not terminate builds. I'll rerun the build, redirect logs and try
greping for perl warnings.

If nothing else pops up, I'd say ready for release.

Stefan
_______________________________________________
gtk-doc-list mailing list
gtk-doc-list@...
http://mail.gnome.org/mailman/listinfo/gtk-doc-list