some questions about sf.net's RFE and bugtracker (statistical data)
Hi!
How can I obtain some statistical about bugreports and RFEs ? Im thinking of: * how many open bugreports/RFEs are at the moment * how many bugreports/RFEs was closed from a given date (ex: from the latest release) * how many bugreports/RFEs need info, etc
Is sf.net is able provide me some of the aboves info?
Khiraly
How can I obtain some statistical about bugreports and RFEs ? Im thinking of:
- how many open bugreports/RFEs are at the moment
- how many bugreports/RFEs was closed from a given date (ex: from the
latest release)
- how many bugreports/RFEs need info, etc
Is sf.net is able provide me some of the aboves info?
You have
1. the statistics available from the Summary page 2. the Admin button from the main page 3. the Admin buttons from the tracker pages (different!)
Some things can be domne with these, not sure.
Last resort is (maybe) becoming paying member at SF and get preferential treatment.
ralf
On Sat, May 20, 2006 at 02:17:56PM +0200, Khiraly wrote:
Hi!
How can I obtain some statistical about bugreports and RFEs ? Im thinking of:
- how many open bugreports/RFEs are at the moment
This can be gotten from the SourceForge stats section.
- how many bugreports/RFEs was closed from a given date (ex: from the
latest release)
This will be more difficult to get, but I think if you sort the bug list by closed date, and filter by state=closed, you can count them manually to find it. This is what i've done in the past to get this info.
- how many bugreports/RFEs need info, etc
There isn't an easy way to get detailed bug info like this, but it'd be very nice if we could.
Is sf.net is able provide me some of the aboves info?
There is also a Perl module at CPAN called WWW::SourceForge that helps to automate scraping info from the SF website. However, when SF changed their web layout earlier this year, it broke the tool. I've submitted patches to help update it, but there's still some things that don't work right.
It may also be possible to download a backup tarball of our SourceForge info database. I've never done that before though so don't know exactly what you'd get, or how easily it could be reused. Might be worth a try, though.
Bryce
configure --prefix=... bails out with:
configure: error: Package requirements (gdkmm-2.4 glibmm-2.4 gtkmm-2.4 gtk+-2.0 >= 2.4.0 libxml-2.0 >= 2.6.11 libxslt >= 1.0.15 sigc++-2.0 >= 2.0.12 gthread-2.0 >= 2.0) were not met. Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.
Have dependencies changed from the list given on:
http://wiki.inkscape.org/wiki/index.php/CompilingMacOsX
Thanks.
On 21/05/06, Andrew Wilson <awilson@...1237...> wrote:
configure --prefix=... bails out with:
configure: error: Package requirements (gdkmm-2.4 glibmm-2.4 gtkmm-2.4 gtk+-2.0 >= 2.4.0 libxml-2.0 >= 2.6.11 libxslt >= 1.0.15 sigc++-2.0 >= 2.0.12 gthread-2.0 >= 2.0) were not met. Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.
Have dependencies changed from the list given on:
Yes, they have.
Last time I checked, we needed sigc++-2.0 >= 2.0.12 (as you quoted), and again, last time I checked, the latest sigc++ in fink was 2.0.11.
I suspect that people sucessfully compiling Inkscape are using their own sigc++ and installing it in /usr/local or some other prefix that is searched before /sw. This does in fact, work for me. I will update the page now, with this info, but we really need some guidance for what advice to give to Mac devs who have been relying on fink.
Grateful for input on this, or any additional observations.
Ben
You wrote
Grateful for input on this, or any additional observations.
This is bug 1492505 and in the works.
People shouldn't rely on svn in such a hot phase of development. If they do, they can certainly change the line in configure.ac, too.
ralf
On 21/05/06, Ralf Stephan <ralf@...748...> wrote:
You wrote
Grateful for input on this, or any additional observations.
This is bug 1492505 and in the works.
Thanks Ralf, I've added your info to the Wiki; With respect to your Bug, are you asking for help - someone to fix up pre-processor macros to enable working with pre-2.0.12 installations of sigc++ to compile and link Inkscape (I doubt that we could make a guarantee that such binaries would always run correctly); or by 'in the works' do you mean that someone is working on it, and a resolution will emerge soon.
Ben
Thanks Ralf, I've added your info to the Wiki; With respect to your Bug, are you asking for help - someone to fix up pre-processor macros to enable working with pre-2.0.12 installations of sigc++ to compile and link Inkscape (I doubt that we could make a guarantee that such binaries would always run correctly); or by 'in the works' do you mean that someone is working on it, and a resolution will emerge soon.
It means it is fixed now in svn and someone on Fink should test it.
ralf
On 21/05/06, Ben Fowler <ben.the.mole@...400...> wrote:
On 21/05/06, Ralf Stephan <ralf@...748...> wrote:
... a resolution will emerge soon.
It means it is fixed now in svn and someone on Fink should test it.
I am just now running make. It is looking good.
Hmmm
I am on r11886 and I am getting errors like ../../src/libnrtype/FontInstance.cpp:519: error: `FT_Outline_MoveToFunc' undeclared (first use this function)
Panther has freetype 2.1.0 . Is this a problem? Is FT_Outline_MoveToFunc the result of a re-name (maybe that doesn't matter anyway)? Do we need some later version? 2.1.4? ./configure doesn't seem to check.
Feel free to undo/redo any changes that I have made to http://wiki.inkscape.org/wiki/index.php/CompilingMacOsX which were merely intended to add the clues would have helped the OP.
Ben
I am on r11886 and I am getting errors like ../../src/libnrtype/FontInstance.cpp:519: error: `FT_Outline_MoveToFunc' undeclared (first use this function)
Those casts on lines 519-522 are unnecessary and hence (as with all unnecessary casts (especially C-style ones)) are potentially unsafe. I've removed them. Does that fix it?
Richard.
On 21/05/06, Richard Hughes <cyreve@...400...> wrote:
I am on r11886 and I am getting errors like ../../src/libnrtype/FontInstance.cpp:519: error: `FT_Outline_MoveToFunc' undeclared (first use this function)
Those casts on lines 519-522 are unnecessary and hence (as with all unnecessary casts (especially C-style ones)) are potentially unsafe. I've removed them. Does that fix it?
Thanks. I am re-spinning r11893.
I apologise if I am making work.
Ben
On 21/05/06, Ben Fowler <ben.the.mole@...400...> wrote:
On 21/05/06, Richard Hughes <cyreve@...400...> wrote:
I am on r11886 and I am getting errors like ../../src/libnrtype/FontInstance.cpp:519: error: `FT_Outline_MoveToFunc' undeclared (first use this function)
Those casts on lines 519-522 are unnecessary and hence (as with all unnecessary casts (especially C-style ones)) are potentially unsafe. I've removed them. Does that fix it?
Thanks. I am re-spinning r11893.
Just doing the final link, so I am pretty sure that this is working. Most grateful for your help.
Ben
On May 21, 2006, at 7:27 AM, Ben Fowler wrote:
Yes, they have.
Last time I checked, we needed sigc++-2.0 >= 2.0.12 (as you quoted), and again, last time I checked, the latest sigc++ in fink was 2.0.11.
I suspect that people sucessfully compiling Inkscape are using their own sigc++ and installing it in /usr/local or some other prefix that is searched before /sw. This does in fact, work for me. I will update the page now, with this info, but we really need some guidance for what advice to give to Mac devs who have been relying on fink.
No.
The problem is that sigc++ 2.0.12 is *only* a problem with gcc 4.0.x
The default for fink is gcc 3.3, which works *fine* with sigc++ 2.0.11
So the dependency on ">= 2.0.12" is only if gcc is also 4.0.x.
Anyone pulling things from fink and doing a straight build will be able to as long as they follow fink's default of using gcc 3.3.
On 21/05/06, Jon A. Cruz <jon@...18...> wrote:
On May 21, 2006, at 7:27 AM, Ben Fowler wrote: [ snip ]
I suspect that people sucessfully compiling Inkscape are using their own sigc++ and installing it in /usr/local or some other prefix that is searched before /sw. This does in fact, work for me. I will update the page now, with this info, but we really need some guidance for what advice to give to Mac devs who have been relying on fink.
No.
The problem is that sigc++ 2.0.12 is *only* a problem with gcc 4.0.x
The default for fink is gcc 3.3, which works *fine* with sigc++ 2.0.11
So the dependency on ">= 2.0.12" is only if gcc is also 4.0.x.
Anyone pulling things from fink and doing a straight build will be able to as long as they follow fink's default of using gcc 3.3.
Thanks Jon, I have updated the Wiki. It would be good if the OP could review this info and report whether it solves the immediate problem.
Do we know if the svn configure.ac handles the various cases: Tiger/Panther gcc 3/gcc 4? I was under the impression that under Panther the later sigc++ was being requested, but this info may be out of date, or simply wrong.
I am just spinning Inkscape again (r11885)
Ben
Ben.
Do we know if the svn configure.ac handles the various cases: Tiger/Panther gcc 3/gcc 4? I was under the impression that under Panther the later sigc++ was being requested, but this info may be out of date, or simply wrong.
At the moment, gcc-4 requires libsigc++-2.0.12 no matter what. Jon Cruz writes that probably gcc-4.1 on Fink would work with 2.0.11, but this is not sure, and hey, why not upgrading your libsigc++. That's the normal way of resolving things.
ralf
On 21/05/06, Ralf Stephan <ralf@...748...> wrote:
[ snip ]
At the moment, gcc-4 requires libsigc++-2.0.12 no matter what. Jon Cruz writes that probably gcc-4.1 on Fink would work with 2.0.11, but this is not sure, and hey, why not upgrading your libsigc++. That's the normal way of resolving things.
FWIW, I did upgrade my sigc++. My point was that once I had read the first post in this thread, I knew that I could not assume that everybody else would be happy to, or know how to.
The interest now is that it looks that following Jon's work, we can continue, in many cases, to use the fink sigc++
Ben
On Sun, 21 May 2006, Ben Fowler wrote:
Last time I checked, we needed sigc++-2.0 >= 2.0.12 (as you quoted), and again, last time I checked, the latest sigc++ in fink was 2.0.11.
I suspect that people sucessfully compiling Inkscape are using their own sigc++ and installing it in /usr/local or some other prefix that is searched before /sw. This does in fact, work for me. I will update the page now, with this info, but we really need some guidance for what advice to give to Mac devs who have been relying on fink.
Since the default fink tree is shortly going to switch to one compiled fully with gcc-4, this will be an issue for fink users soon. For this reason, as I mentioned on the list a couple of days ago, I have emailed the maintainer of the libsigc++2 package in fink requesting that it please be updated.
In the meantime I'm using a locally updated fink package to provide version libsigc++-2.0.17 and everything builds and runs fine with gcc-4.
Cheers, Michael
On 21/05/06, Michael Wybrow <mjwybrow@...1047...> wrote:
On Sun, 21 May 2006, Ben Fowler wrote:
[ snip ]
Since the default fink tree is shortly going to switch to one compiled fully with gcc-4, this will be an issue for fink users soon. For this reason, as I mentioned on the list a couple of days ago, I have emailed the maintainer of the libsigc++2 package in fink requesting that it please be updated.
In the meantime I'm using a locally updated fink package to provide version libsigc++-2.0.17 and everything builds and runs fine with gcc-4.
Thank you, that is very clear and accords with what I have seen. I think the point is that after the work done by Jon and Ralf, at least some fink users can still compile Inkscape (using gcc 3). In fact it is possible that the problem as originally reported is now fixed.
If anyone wants to amend the CompilingMacOsX page that would be good (as one of the things that this thread has been about is introductory documentation), or I will have another go in a day or two.
It is a pity that there seems to be nobody here who does fink (or vice versa) and I fear that the fink project may be pressed for personnel.
Ben
participants (8)
-
Andrew Wilson -
Ben Fowler -
Bryce Harrington -
Jon A. Cruz -
Khiraly -
Michael Wybrow -
Ralf Stephan -
Richard Hughes