- Inkscape Devel - Inkscape Mailman

Required bugs to fix for 0.39
by Bryce Harrington 12 Jul '04

12 Jul '04

The following bugs have been identified as 'required fixes' for the Inkscape 0.39 release: 984902 (CLOSED) "paint-selector.cpp: patternmenu getting destroyed" 979858 (OPEN 9) "image xlink: pixmaps linked with relative path don't work" 978391 (OPEN 9) "Autopackage installation" 978250 (OPEN 9) "mkinstalldirs error." Bulia also mentioned some export dialog issues, but there isn't a ticket number associated with it yet, so it's unclear what the status is. I've reduced the other other critical bugs to level 8. Bryce

2 4

testing...
by Bryce Harrington 12 Jul '04

12 Jul '04

Is this thing on...?

1 0

Re: [Inkscape-devel] autopackage now requires explicit --enable-binreloc
by Kees Cook 11 Jul '04

11 Jul '04

On Sun, Jul 11, 2004 at 03:34:39PM -0700, Mike Hearn wrote: > On Sun, 2004-07-11 at 14:04 -0700, Kees Cook wrote: > > We've disabled binreloc by default so that some of the other developers > > aren't disturbed by it. In the meantime, if your nightly builds can be > > changed to add "--enable-binreloc" to the "configure" run, Inkscape will > > correctly compile binreloc. > > Yes, I modified the specfile to do that. I tracked it down to header > ordering - in some cases config.h was being included after prefix.h > which was redefining the relevant macros. I think it's fixed now - I > guess prefix.h including config.h would fix that too. > > As to -D flags vs config.h entries, well, I don't know enough about > autoheader/autoconf to comment I'm afraid so I'll let Hongli deal with > that. Whoops, I'm not on the list, can you CC me on replies? :) Bryce forwarded me your response. I have an updated patch that makes prefix.c C++ type-safe. As for the config.h entries, I'd love to see where autoheader is considered deprecated. At least according to the documentation from autoconf 2.59, I see no mention of autoheader going away. Using "make" to detect changes in your build system won't pay attention to -D flags, but it will see changes in the config.h. With large packages (like inkscape), I don't want to have to do a full recompile. Also, for the end user who is attempting to compile the program, they shouldn't have to know which files to delete or to do a "make clean" if they decide to change a "configure" option. I should be able to run "configure --disable-binreloc", "make", and then "configure --enable-binreloc", "make" and have things correctly rebuild. Without the config.h entries, this is not happening. If people aren't using config.h, then they won't have an "AM_CONFIG_HEADER"/"AC_CONFIG_HEADER" call in their configure.ac, so my patch stands: for those using CFLAGS, it will work. For those using config.h it will work. And neither will step on the others' toes. :) -- Kees Cook @outflux.net

1 0

Re: [Inkscape-devel] autopackage now requires explicit --enable-binreloc (fwd)
by Hongli Lai 11 Jul '04

11 Jul '04

Bryce Harrington wrote: > - The code for enable-binreloc=auto (which was previously the default) > checked the build environment rather than the execution environment. ??? What does this mean? > - autopackage code prevents running inkscape from the build directory. > (This problem is reduced if the source directory and the build > directory are the same.) > > It should fall back to using the configure-supplied PREFIX value. I don't think this is possible except if you explicitly code fallback functions in the application. > - br_locate uses sscanf("%x-%x") and unsigned ints whereas > linux/fs/proc/array.c uses printf("%08lx-%08lx") and unsigned > longs. This presumably leads to bugs on 64-bit platforms. That's because Mike's patch uses an old version of BinReloc. The CVS BinReloc uses unsigned longs and "%lx" (maybe I should change that to "%08lx" instead? not sure). > - br_prepend_prefix needlessly requires that its path argument be > writable. It doesn't. br_prepend_prefix doesn't modify the content of the path argument in any way. I just didn't use the 'const' keyword, that's all. ;) > - br_strcat uses calloc, only to write over the space. It in > effect calculates strlen(str1) 3 times and strlen(str2) twice. Should be fixed in the autopackage CVS now. > - br_strndup has buffer overflow if size excedes the length of str > by more than one. Thanks for the tip. Fixed in CVS now. > - br_extract_prefix doesn't behave as its documentation indicates. This is a typo in the documentation. Fixed. > Also it does an unnecessary strndup when it could use memrchr. I'm not sure which line exactly you're referring to.

4 4

Clarification of 0.40 tasks?
by Bryce Harrington 11 Jul '04

11 Jul '04

Could someone elaborate on what the following task items mean? In particular, I'm wondering if they still belong in the 0.40 release todo list. * Make clones respond sensibly to original duplication * Reenable fuzzy font matching * Make gradient management & chaining work similar to patterns ** Fix fill-opacity ignored with gradients * Implement "Select Under" * Complete the cursor icons set * Redraw old icons to look decent Thanks, Bryce

4 5

Bug Stats
by Bryce Harrington 11 Jul '04

11 Jul '04

Date Crit Open Total Ratio 7/1 88 452 19.5% 7/4 8 89 464 19.2%

1 9

SEGV & SIGABRT handlers
by Bryce Harrington 11 Jul '04

11 Jul '04

Kees, Do you feel that the handlers for SEGV and SIGABRT reliably auto-save and put up crash dialogs? This is an item on the roadmap for 0.40, but I think you probably already took care of it. If so, we can cross that item off the list. Bryce

2 2

svg align icons
by Aubanel MONNIER 11 Jul '04

11 Jul '04

just to let you know I attached new svg align icons to the patch tracker.

1 0

gtkmm and sigc++ version
by Aubanel MONNIER 11 Jul '04

11 Jul '04

Hi list, while trying to resolve some basinc problems I had with tentatives of gtkmmification, I jumped on the #c++ channel on irc.gnome.org, and founs very nice people explaining that we should not rely on a deprecated version of gtkmm and sigc++. So with their help I made the port to gtkmm2.4 (nothing to do, configure.in was ready) and libsigc++2.0, which took a bit more time. This does not fix my problem, but it works. So if anyone is interested, I can semd a patch. Let me know what the procedure is. Thx, obi.

4 7

Proposal for 0.39 freeze
by Bryce Harrington 11 Jul '04

11 Jul '04

It feels like things are getting close to being ready for a freeze, and to start preparing for the release. There's a lot of work still going on, and we don't want to interrupt things abruptly, so it may be worthwhile to settle on some loose target dates. How does the following plan sound? 1. 'Feature chill' - June 28. No new features should be started, work should be wrapping up on existing features and code cleanup. Unfinished features should be hidden. Focus should be on bug fixing. 2. 'Feature freeze' - Sometime in first week of July. Only bug fixing should occur after this point. Focus should be on closing critical bugs and bugs in new features. 3. 'Hard freeze' - When all major bugs have been closed that we intend to close, we go into a short hard freeze period for a few days where no changes are allowed except under strict change control. We do final QA, verify on as many platforms as possible, create the packages and verify they work well, and make sure no last minute bugs slipped in. 4. 'Release' Bryce

12 28