GNOME Bugzilla – Bug 608728
Add gtksourceviewmm API reference
Last modified: 2011-01-28 10:08:42 UTC
Can gtksourceviewmm API docs be added to library.gnome.org? Latest stable version tarball: http://download.gnome.org/sources/gtksourceviewmm/2.2/gtksourceviewmm-2.2.0.tar.gz Latest unstable version tarball: http://download.gnome.org/sources/gtksourceviewmm/2.9/gtksourceviewmm-2.9.1.tar.gz Also, I'd like to know how/where to mention that an API reference in library.gnome.org needs to be updated. I mean - I released and announced [1] two versions of gtksourceviewmm and it was not put inside library, so it is not automagic. Also, I maintain libvtemm and in library there is API reference only for unstable 0.23.1, while latest stable API reference [0.22.2] [2] is not available. So I'm missing something. Thanks. [1] On gnome-announce-list. [2] http://download.gnome.org/sources/libvtemm/0.22/libvtemm-0.22.2.tar.gz
I had a look at gtksourceviewmm but there is a problem at the moment, the tarball is created in POSIX.1-2001 pax format and the version of Python on the server doesn't support them, and truncate long filenames to 100 characters. It is fixed in Python 2.6 but in the meantime it would be most useful if you could create tarballs in the GNU tar format, that is fully compatible with older Python releases. About your libvtemm question this is because library.gnome.org considers any 0. version to be a development release, and only keeps the latest version.
(In reply to comment #1) > I had a look at gtksourceviewmm but there is a problem at the moment, the > tarball is created in POSIX.1-2001 pax format and the version of Python on the > server doesn't support them, and truncate long filenames to 100 characters. > > It is fixed in Python 2.6 but in the meantime it would be most useful if you > could create tarballs in the GNU tar format, that is fully compatible with > older Python releases. Are you talking about stable 2.2.0 or unstable 2.9.1? If about the former then don't upload it then, please - it will be replaced soon by new stable 2.10. If about the latter, then it is strange, because gtksourceviewmm and gtkmm/glibmm/libvtemm use the same format of tar.gz and they somehow find their way into library. That is maybe because usually tar.bz2 is uploaded to master.gnome.org and then install-module creates a .tar.gz from it. > About your libvtemm question this is because library.gnome.org considers any 0. > version to be a development release, and only keeps the latest version. So it has to be overriden, right? Like vte [1] which libvtemm wraps. [1] http://library.gnome.org/devel/vte/
1) Perhaps there are no file with such long names in the other libraries, or at least I didn't notice them, and there are now broken links. 2) There is no override mechanism for this, vte appears multiple times as it is part of the official modulesets, and all tarballs mentioned in published modulesets are used.
I tried to use 'tar-v7 filename-length-max=99' options in AM_INIT_AUTOMAKE and some files generated by Doxygen indeed have too long filenames. Since these files are generated and I probably have no way to change Doxygen's generating filename behavior, I'll have to wait until python 2.6 is installed. In the meantime I'll put API reference to projects.gnome.org.
Can't you just use whatever build stuff gtkmm uses?
(In reply to comment #5) > Can't you just use whatever build stuff gtkmm uses? That does not fix the pax tar issue, which is required for any tarball where filenames are longer than 100 characters. Besides, libvtemm already uses mm-common. Also, gtkmm uses the pax tar format too, so is a bad example.
Why doesn't gtkmm have a problem with library.gnome.org then?
(In reply to comment #7) > Why doesn't gtkmm have a problem with library.gnome.org then? It does. See the broken link (no inheritance graph) here: http://library.gnome.org/devel/gtkmm/stable/classGtk_1_1ComboDropDown__Helpers_1_1ComboDropDownList.html Glibmm even has missing pages: http://library.gnome.org/devel/glibmm/stable/namespaceGlib_1_1Container__Helpers.html (click the TypeTraits< Glib::RefPtr< Gio::Volume > > link). This probably affects several mm modules.
CCing Daniel Elstner, who probably knows what to do.
> It is fixed in Python 2.6 Fred, is this likely to be fixed on the library server any time soon?
(In reply to comment #9) > CCing Daniel Elstner, who probably knows what to do. Krzesimir and David are right, the long filenames produced by Doxygen are the reason we switched over most C++ binding modules to the tar-pax format, because even tar-ustar turned out to be not sufficient. There is no way to avoid this on our side, short of making Doxygen produce meaningless 8.3 filenames, which is not an option. Unfortunately Doxygen lacks support for anything in between. We've been using the new POSIX tar format for quite a while now (more than one year at least), and this is the first actual incompatibility I hear of. I think fixing this on the server is the only sensible option.
What's the current status? Is there any reason not to put gtksourceviewmm on library.gnome.org, given that the other C++ binding modules also use POSIX tar format?
Frederic, can we just add this and live with a few files being wrongly named, with a few broken links, as we apparently do for the other *mm modules?
Frederic?
Sorry, missed that previous comment. commit d2b1344ce1439dac9cc49a8d7584bcdbf363eef1 Author: Frédéric Péters <fpeters@0d.be> Date: Fri Jan 28 11:06:49 2011 +0100 Add gtksourceviewmm (GNOME bug 608728)