Re: [draft] Release plans for 1.9.0?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [draft] Release plans for 1.9.0?

Christian Stimming
Dear gnucash developers,

almost two weeks ago I proposed a release schedule for the upcoming
unstable 1.9.x release series. See
https://lists.gnucash.org/pipermail/gnucash-devel/2006-January/015658.html
and http://wiki.gnucash.org/wiki/Release_Schedule

The goal of the 1.9.x series, starting with 1.9.0, is to provide easier
access for testers to a source package. The goal is *not* to be at the
"all pieces ported fully to g2" state! Instead, all of these releases
will be clearly marked as "work in progress", but I guess we will
immediately get a much broader testing audience once we actually start
to distribute the unstable tarballs.

That said, I proposed in that original mail to have the initial 1.9.0
release quite soon, namely on next Sunday, January 29th. The question
is: What do think needs to be finished before a 1.9.0 release?  Because
if there isn't any outstanding issue, we could just as well go ahead and
in fact *do* the 1.9.0 release this Sunday. Whoa.

One answer is given by the outstanding bugs in bugzilla which are marked
with milestone=1.9.0:
http://bugzilla.gnome.org/buglist.cgi?product=GnuCash&target_milestone=1.9.0 

If you have any more issues, please always add them to bugzilla.
http://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash If you think
these should be fixed before a particular release, mark them with the
respective milestone.

That query currently says there is one more bug that should be fixed
before 1.9.0, namely the "Crash on opening 1.8 datafile with renamed
reports". But it's not clear whether this has been fixed by Chris and/or
cannot be reproduced anymore. If it isn't that much of an issue any
longer then maybe we can move it to a later target. If it is still an
issue then we need to fix it.

So. What are we going to do? Having a 1.9.0 release this Sunday might
sound agressive, but OTOH what do we gain by postponing to some later
point in time? If there are particular issues that we think need to be
resolved, then I'd propose just the next weekend: Feb 5th. But if there
aren't any more issues, then we can just take this weekend...

We'd still need to point out somebody as the designated release dude who
will prepare and upload the tarball. Chris Lyttle did this in 1.8.x.
Chris, would you be available to do this for 1.9.x as well or should we
point out someone else?

What do people think?

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [draft] Release plans for 1.9.0?

Josh Sled
On Thu, 2006-01-26 at 16:17 +0100, Christian Stimming wrote:
> If you have any more issues, please always add them to bugzilla.
> http://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash If you think
> these should be fixed before a particular release, mark them with the
> respective milestone.

[Slight tangent...] This assumes that we do know they should be fixed
before a particular release, but there's two ways to approach the case
where we know they should be fixed before 2.0, but don't know in which
particular release they will/should be fixed in.  There's two
approaches:

- "push-out": assign all un-slotted bugs to the next release, then
immediately before that release goes out push-out the ones that aren't
going to make it.

- "pull-in": assign all un-slotted bugs to the 2.0.0 target, then pull
in the ones that have-been- or need-to-be-fixed before a particular
milestone.

As we were just talking about on IRC, I think the later "pull-in"
strategy is less-depressing :), though it takes a bit of discipline for
developers to include both the next milestone and the 2.0.0 milestone in
queries in order to get a sense of what needs/can be done for a
particular release.

In any case, I think the project should roughly agree on one approach
over the other, and I think it's "pull-in".  Objections?


> That query currently says there is one more bug that should be fixed
> before 1.9.0, namely the "Crash on opening 1.8 datafile with renamed
> reports". But it's not clear whether this has been fixed by Chris and/or
> cannot be reproduced anymore. If it isn't that much of an issue any
> longer then maybe we can move it to a later target. If it is still an
> issue then we need to fix it.

I've another 2-4 bugs that I have-fixed (and not yet committed) or hope
to fix before Sunday.  The "crash on renamed report" is not among them,
however.


> What do people think?

1.9.0 this sunday.

--
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [draft] Release plans for 1.9.0?

Chris Shoemaker
In reply to this post by Christian Stimming
On Thu, Jan 26, 2006 at 04:17:53PM +0100, Christian Stimming wrote:

> Dear gnucash developers,
>
> almost two weeks ago I proposed a release schedule for the upcoming
> unstable 1.9.x release series. See
> https://lists.gnucash.org/pipermail/gnucash-devel/2006-January/015658.html
> and http://wiki.gnucash.org/wiki/Release_Schedule
>
> The goal of the 1.9.x series, starting with 1.9.0, is to provide easier
> access for testers to a source package. The goal is *not* to be at the
> "all pieces ported fully to g2" state! Instead, all of these releases
> will be clearly marked as "work in progress", but I guess we will
> immediately get a much broader testing audience once we actually start
> to distribute the unstable tarballs.
>
> That said, I proposed in that original mail to have the initial 1.9.0
> release quite soon, namely on next Sunday, January 29th. The question
> is: What do think needs to be finished before a 1.9.0 release?  

Last time I checked, 'make distcheck' still fails, but 'make check'
passes.  I have some vague impression that this might cause packaging
difficulties.

> Because
> if there isn't any outstanding issue, we could just as well go ahead and
> in fact *do* the 1.9.0 release this Sunday. Whoa.

One thing I'd like to include in 1.9.0 is a gnucash-debug script that
runs gnucash under gdb.

> One answer is given by the outstanding bugs in bugzilla which are marked
> with milestone=1.9.0:
> http://bugzilla.gnome.org/buglist.cgi?product=GnuCash&target_milestone=1.9.0 
>
> If you have any more issues, please always add them to bugzilla.
> http://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash If you think
> these should be fixed before a particular release, mark them with the
> respective milestone.
>
> That query currently says there is one more bug that should be fixed
> before 1.9.0, namely the "Crash on opening 1.8 datafile with renamed
> reports". But it's not clear whether this has been fixed by Chris and/or
> cannot be reproduced anymore. If it isn't that much of an issue any
> longer then maybe we can move it to a later target. If it is still an
> issue then we need to fix it.

I can reproduce it.  At least, I get the "there had been an error in
the report" message, but not a crash.

> So. What are we going to do? Having a 1.9.0 release this Sunday might
> sound agressive, but OTOH what do we gain by postponing to some later
> point in time? If there are particular issues that we think need to be
> resolved, then I'd propose just the next weekend: Feb 5th. But if there
> aren't any more issues, then we can just take this weekend...
>
> We'd still need to point out somebody as the designated release dude who
> will prepare and upload the tarball. Chris Lyttle did this in 1.8.x.
> Chris, would you be available to do this for 1.9.x as well or should we
> point out someone else?
>
> What do people think?

One issue I've been meaning to raise for a while, but ... better late
than never:  

I think we should totally change the way we produce the NEWS entries.
We should be reporting on significant user-visible changes in the NEWS
file.  I think that we should be making those entries at the _same_
time as the changes themselves.  We can have an accumulator of entries
at the top of the file and then just date and version it at
release-time and start an empty accumulator.

It's tempting to procrastinate but I think it's best to maintain NEWS
as-we-go.  I'll try to commit some entries.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [draft] Release plans for 1.9.0?

Derek Atkins
Quoting Chris Shoemaker <[hidden email]>:

> Last time I checked, 'make distcheck' still fails, but 'make check'
> passes.  I have some vague impression that this might cause packaging
> difficulties.

I'll play around with this when I can...  Usually it's "make check" that
causes "make distcheck" to fail.  If "make check" works then usually
distcheck fails because of missing EXTRA_DIST files.  I'll take a look.

> One thing I'd like to include in 1.9.0 is a gnucash-debug script that
> runs gnucash under gdb.

Speaking of which, I think you removed the gnucash-run-script from
src/bin/overrides but not src/bin -- what's up with that?

> I think we should totally change the way we produce the NEWS entries.
> We should be reporting on significant user-visible changes in the NEWS
> file.  I think that we should be making those entries at the _same_
> time as the changes themselves.  We can have an accumulator of entries
> at the top of the file and then just date and version it at
> release-time and start an empty accumulator.
>
> It's tempting to procrastinate but I think it's best to maintain NEWS
> as-we-go.  I'll try to commit some entries.

I think this "main NEWS as-we-go" makes sence for patchlevel releases
(e.g. 1.9.0->1.9.1, 1.9.1->1.9.2, etc).   I don't think it makes sense
for major releases (1.8->2.0).  There's just WAY WAY WAY too much to
keep track of as you go for a major release.

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [draft] Release plans for 1.9.0?

Chris Shoemaker
In reply to this post by Josh Sled
On Thu, Jan 26, 2006 at 11:07:47AM -0500, Josh Sled wrote:

> On Thu, 2006-01-26 at 16:17 +0100, Christian Stimming wrote:
> > If you have any more issues, please always add them to bugzilla.
> > http://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash If you think
> > these should be fixed before a particular release, mark them with the
> > respective milestone.
>
> [Slight tangent...] This assumes that we do know they should be fixed
> before a particular release, but there's two ways to approach the case
> where we know they should be fixed before 2.0, but don't know in which
> particular release they will/should be fixed in.  There's two
> approaches:
>
> - "push-out": assign all un-slotted bugs to the next release, then
> immediately before that release goes out push-out the ones that aren't
> going to make it.
>
> - "pull-in": assign all un-slotted bugs to the 2.0.0 target, then pull
> in the ones that have-been- or need-to-be-fixed before a particular
> milestone.
>
> As we were just talking about on IRC, I think the later "pull-in"
> strategy is less-depressing :), though it takes a bit of discipline for
> developers to include both the next milestone and the 2.0.0 milestone in
> queries in order to get a sense of what needs/can be done for a
> particular release.
>
> In any case, I think the project should roughly agree on one approach
> over the other, and I think it's "pull-in".  Objections?

Personally, I think "push-out" makes a lot more sense.  I don't think
we should feel any qualms about bumping all open bugs to the next
milestone at release-time.  That's just life.  AFAICT, the milestone
is intended to express "what bugs are candidates for being fixed in
that release."  The only reason why a bug wouldn't be marked for the
next milestone is that someone decided that the fix involves changes
that shouldn't be made before that release.  Marking them for a later
milestone just because we don't know when we'll get to them seems...
less useful.  I mean, if we mark all bugs milestones as the farthest
out-release, what information does that contain, other than
NotFixedYet?  And how could we use that field to convey meaning?

> > What do people think?
>
> 1.9.0 this sunday.

My only concerns are packaging, not features or bugs.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [draft] Release plans for 1.9.0?

Chris Shoemaker
In reply to this post by Derek Atkins
On Thu, Jan 26, 2006 at 07:58:06PM -0500, Derek Atkins wrote:

> Quoting Chris Shoemaker <[hidden email]>:
>
> >Last time I checked, 'make distcheck' still fails, but 'make check'
> >passes.  I have some vague impression that this might cause packaging
> >difficulties.
>
> I'll play around with this when I can...  Usually it's "make check" that
> causes "make distcheck" to fail.  If "make check" works then usually
> distcheck fails because of missing EXTRA_DIST files.  I'll take a look.
>
> >One thing I'd like to include in 1.9.0 is a gnucash-debug script that
> >runs gnucash under gdb.
>
> Speaking of which, I think you removed the gnucash-run-script from
> src/bin/overrides but not src/bin -- what's up with that?

It's not in svn.

> >I think we should totally change the way we produce the NEWS entries.
> >We should be reporting on significant user-visible changes in the NEWS
> >file.  I think that we should be making those entries at the _same_
> >time as the changes themselves.  We can have an accumulator of entries
> >at the top of the file and then just date and version it at
> >release-time and start an empty accumulator.
> >
> >It's tempting to procrastinate but I think it's best to maintain NEWS
> >as-we-go.  I'll try to commit some entries.
>
> I think this "main NEWS as-we-go" makes sence for patchlevel releases
> (e.g. 1.9.0->1.9.1, 1.9.1->1.9.2, etc).   I don't think it makes sense
> for major releases (1.8->2.0).  There's just WAY WAY WAY too much to
> keep track of as you go for a major release.

I'm not sure what you mean.  Maintaining as we go means no huge chunk
of work at any release.  Or are you saying we should do that from now
on, but not for 1.9.0, since there's so much that changed?  I'm not
suggesting that we should record more than normal, just that we record
it at the same time as the change instead of at release-time.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [draft] Release plans for 1.9.0?

Derek Atkins
Quoting Chris Shoemaker <[hidden email]>:

>> Speaking of which, I think you removed the gnucash-run-script from
>> src/bin/overrides but not src/bin -- what's up with that?
>
> It's not in svn.

Sorry, was looking in the wrong directory.

>> I think this "main NEWS as-we-go" makes sence for patchlevel releases
>> (e.g. 1.9.0->1.9.1, 1.9.1->1.9.2, etc).   I don't think it makes sense
>> for major releases (1.8->2.0).  There's just WAY WAY WAY too much to
>> keep track of as you go for a major release.
>
> I'm not sure what you mean.  Maintaining as we go means no huge chunk
> of work at any release.  Or are you saying we should do that from now
> on, but not for 1.9.0, since there's so much that changed?  I'm not
> suggesting that we should record more than normal, just that we record
> it at the same time as the change instead of at release-time.

Well, there's always a huge amount of work at a release...  There's not
just packaging the code (and maybe building packages) but there's also
writing up the release announcement, etc.   Running through the ChangeLog
and finding what's been changed between releases usually isn't that much
work.

I'm also suggesting that we shouldn't worry about between ANY major
releases (1.8->1.9/2.0,  2.0->2.1/2.2, etc.)..  Also, I'm not sure we
want NEWS to churn as much as ChangeLog.

> -chris

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [draft] Release plans for 1.9.0?

Chris Lyttle
In reply to this post by Christian Stimming
On Thu, 2006-01-26 at 16:17 +0100, Christian Stimming wrote:

> almost two weeks ago I proposed a release schedule for the upcoming
> unstable 1.9.x release series. See
> https://lists.gnucash.org/pipermail/gnucash-devel/2006-January/015658.html
> and http://wiki.gnucash.org/wiki/Release_Schedule

> We'd still need to point out somebody as the designated release dude who
> will prepare and upload the tarball. Chris Lyttle did this in 1.8.x.
> Chris, would you be available to do this for 1.9.x as well or should we
> point out someone else?
>

I can handle that release schedule as release engineer. My only caveat
is that I can get things to compile successfully on my gentoo box. As
its running ~amd64 (unstable amd 64 compiled code for non-gentooers) and
that this doesn't cause a problem for people who are on x86. If it does
cause problems I can fall back to compiling on my x86 (stable x86
compiled code) box, which would just take a bit longer to compile. In
fact, thinking about that I could compile the resulting tarball on my
x86 box to test it before release. As I'm familiar with the process from
last time (1.7.x) I think this would be easier than getting a new guy up
to speed. BTW I am in no way volunteering to make rpm's or any type of
pre-compiled package.

Chris
--
RedHat Certified Engineer #807302549405490.
Checkpoint Certified Security Expert 2000 & NG
--------------------------------------------
        |^|
        | |   |^|
        | |^| | |  Life out here is raw
        | | |^| |  But we will never stop
        | |_|_| |  We will never quit
        | / __> |  cause we are Metallica
        |/ /    |
        \       /
         |     |
--------------------------------------------

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [draft] Release plans for 1.9.0?

Chris Lyttle
In reply to this post by Derek Atkins
On Thu, 2006-01-26 at 19:58 -0500, Derek Atkins wrote:

> > I think we should totally change the way we produce the NEWS entries.
> > We should be reporting on significant user-visible changes in the NEWS
> > file.  I think that we should be making those entries at the _same_
> > time as the changes themselves.  We can have an accumulator of entries
> > at the top of the file and then just date and version it at
> > release-time and start an empty accumulator.
> >
> > It's tempting to procrastinate but I think it's best to maintain NEWS
> > as-we-go.  I'll try to commit some entries.
>
> I think this "main NEWS as-we-go" makes sence for patchlevel releases
> (e.g. 1.9.0->1.9.1, 1.9.1->1.9.2, etc).   I don't think it makes sense
> for major releases (1.8->2.0).  There's just WAY WAY WAY too much to
> keep track of as you go for a major release.
>

Sorry Chris, but as release engineer I have to agree with Derek here.
I've no problem with the NEWS file being updated as you go for this beta
series, but major releases are another matter. My process for major
releases is to comb through the Changelog to compile information for the
NEWS file, this makes the NEWS file both readable and informative for
non-developers about the release. This process is in fact a relatively
minor part of each release, I spend much more time testing and
compiling.

Chris
--
RedHat Certified Engineer #807302549405490.
Checkpoint Certified Security Expert 2000 & NG
--------------------------------------------
        |^|
        | |   |^|
        | |^| | |  Life out here is raw
        | | |^| |  But we will never stop
        | |_|_| |  We will never quit
        | / __> |  cause we are Metallica
        |/ /    |
        \       /
         |     |
--------------------------------------------

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Proposal: Release 1.9.0 today

Christian Stimming
In reply to this post by Chris Lyttle
Hi Chris and all,

Am Samstag, 28. Januar 2006 03:31 schrieb Chris Lyttle:
> > almost two weeks ago I proposed a release schedule for the upcoming
> > unstable 1.9.x release series.
>
> I can handle that release schedule as release engineer.

Good to hear! Thanks a lot.

> As I'm familiar with the process from
> last time (1.7.x) I think this would be easier than getting a new guy up
> to speed. BTW I am in no way volunteering to make rpm's or any type of
> pre-compiled package.

Tarballs are totally fine. We shouldn't bother with anything precompiled
during this 1.9.x series. We can consider this issue again for 2.0.0, but
now.

Ok, as now the bugs in bugzilla according to
http://wiki.gnucash.org/wiki/Release_Schedule don't seem to cause any
immediate crash and/or immediate data loss, I would actually propose to
GO FOR IT! Let's have a 1.9.0 today! Yeah! :-)

I've prepared a draft announcement here:  
http://wiki.gnucash.org/wiki/Announcement_1.9.0 
Chris, you should be able to directly copy&paste it into everywhere where
needed. Or anyone else could still edit it and improve the english in there.

Chris would then prepare the tarball, tag the CVS -- err, how is this done in
SVN? Then let's have a 1.9.0 tonight and we'll see how many people will show
up during the next weeks...

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Release 1.9.0 today

Derek Atkins
Quoting Christian Stimming <[hidden email]>:

> Ok, as now the bugs in bugzilla according to
> http://wiki.gnucash.org/wiki/Release_Schedule don't seem to cause any
> immediate crash and/or immediate data loss, I would actually propose to
> GO FOR IT! Let's have a 1.9.0 today! Yeah! :-)

Actually, 328790 causes data loss...  I've only half-fixed it.

-derek
--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Release 1.9.0 today

Chris Lyttle
OK and I dont seem to be able to get distcheck to work. It compiles ok
initially, just when it gets into the distcheck part it dies.

Guess we'll have to hold that thought about a release today!

Chris

Making dvi in design
make[4]: Entering directory
`/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/src/doc/design'
TEXINPUTS="../../../../src/doc/design:$TEXINPUTS" \
MAKEINFO='/bin/sh /home/chris/cvs/gnucash-test/gnucash-1.9.0/missing
--run makeinfo   -I ../../../../src/doc/design' \
texi2dvi ../../../../src/doc/design/gnucash-design.texinfo
This is e-TeX, Version 3.141592-2.2 (Web2C 7.5.5)
I can't find the format file `etex.fmt'!
kpathsea: Running mktexfmt etex.fmt
tcfmgr: config file `tcfmgr.map' (usually in $TEXMFMAIN/texconfig) not
found.
fmtutil: config file `fmtutil.cnf' not found.
/usr/bin/texi2dvi: texinfo.tex appears to be broken, quitting.
make[4]: *** [gnucash-design.dvi] Error 1
make[4]: Leaving directory
`/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/src/doc/design'
make[3]: *** [dvi-recursive] Error 1
make[3]: Leaving directory
`/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/src/doc'
make[2]: *** [dvi-recursive] Error 1
make[2]: Leaving directory
`/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/src'
make[1]: *** [dvi-recursive] Error 1
make[1]: Leaving directory
`/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build'
make: *** [distcheck] Error 2


On Sun, 2006-01-29 at 11:10 -0500, Derek Atkins wrote:

> Quoting Christian Stimming <[hidden email]>:
>
> > Ok, as now the bugs in bugzilla according to
> > http://wiki.gnucash.org/wiki/Release_Schedule don't seem to cause any
> > immediate crash and/or immediate data loss, I would actually propose to
> > GO FOR IT! Let's have a 1.9.0 today! Yeah! :-)
>
> Actually, 328790 causes data loss...  I've only half-fixed it.
>
> -derek
--
RedHat Certified Engineer #807302549405490.
Checkpoint Certified Security Expert 2000 & NG
--------------------------------------------
        |^|
        | |   |^|
        | |^| | |  Life out here is raw
        | | |^| |  But we will never stop
        | |_|_| |  We will never quit
        | / __> |  cause we are Metallica
        |/ /    |
        \       /
         |     |
--------------------------------------------

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Release 1.9.0 today

Christian Stimming
Hi Chris,

Chris Lyttle schrieb:

> make[4]: Entering directory
> `/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/src/doc/design'
> TEXINPUTS="../../../../src/doc/design:$TEXINPUTS" \
> MAKEINFO='/bin/sh /home/chris/cvs/gnucash-test/gnucash-1.9.0/missing
> --run makeinfo   -I ../../../../src/doc/design' \
> texi2dvi ../../../../src/doc/design/gnucash-design.texinfo
> This is e-TeX, Version 3.141592-2.2 (Web2C 7.5.5)
> I can't find the format file `etex.fmt'!
> kpathsea: Running mktexfmt etex.fmt
> tcfmgr: config file `tcfmgr.map' (usually in $TEXMFMAIN/texconfig) not
> found.
> fmtutil: config file `fmtutil.cnf' not found.
> /usr/bin/texi2dvi: texinfo.tex appears to be broken, quitting.

Your texinfo and/or tetex installation seems to have a problem. These
distcheck errors haven't been reported in the near past. Seems to me a
local problem at your machine?

$ find /usr/share/tex* -name tcfmgr.map
/usr/share/texmf/texconfig/tcfmgr.map
$ find /usr/share/tex* -name fmtutil.cnf
/usr/share/texmf/web2c/fmtutil.cnf
$ rpm -qf /usr/share/texmf/texconfig/tcfmgr.map
/usr/share/texmf/web2c/fmtutil.cnf
tetex-3.0-13
tetex-3.0-13

I'd propose that we still go for it, today.
http://wiki.gnucash.org/wiki/Release_Schedule  and
http://wiki.gnucash.org/wiki/Announcement_1.9.0

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Release 1.9.0 today

Chris Lyttle
OK I managed to get past the tex problem. Was a bug in the 3.0 version,
downgrading fixed it. I'm still unable to get a compile to work tho;

on amd64 I get,

qif loading
"../../../../../src/import-export/qif/test/test-files/test-1-bank-txn.qif"...
*** glibc detected *** double free or corruption (fasttop):
0x000000000054dea0 ***
/bin/sh: line 1: 27224 Aborted
GNC_TEST_FILES=../../../../../src/import-export/qif/test/test-files
GNC_MODULE_PATH=
${GNC_MODULE_PATH}:../../../../src/core-utils:../../../../src/gnc-module:../../../../src/engine:../../../../src/app-utils:../../../../src/import-export:../../../../src/import-export/qif:../../../../src/calculation:../../../../src/gnome-utils:../../../../../src/gnc-module:../../../../../src/engine:../../../../../src/app-utils:../../../../../src/gnome-utils:../../../../src/gnome-utils:../../../../src/network-utils:../../../../src/gnome GUILE_LOAD_PATH=${GUILE_LOAD_PATH}:../../../../src/core-utils:../../../../src/gnc-module:../../../../src/engine:../../../../src/app-utils:../../../../src/import-export:../../../../src/import-export/qif:../../../../src/calculation:../../../../src/gnome-utils:../../../../../src/gnc-module:../../../../../src/engine:../../../../../src/app-utils:../../../../../src/gnome-utils:../../../../src/gnome-utils:../../../../src/network-utils:../../../../src/gnome:/usr/share/guile:../../../../../src/scm:../../../../../src/import-export:../../../../../src/impor!
 t-export/qif LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:../../../../src/core-utils:../../../../src/core-utils/.libs:../../../../src/gnc-module:../../../../src/gnc-module/.libs:../../../../src/engine:../../../../src/engine/.libs:../../../../src/app-utils:../../../../src/app-utils/.libs:../../../../src/import-export:../../../../src/import-export/.libs:../../../../src/import-export/qif:../../../../src/import-export/qif/.libs:../../../../src/calculation:../../../../src/calculation/.libs:../../../../src/gnome-utils:../../../../src/gnome-utils/.libs:../../../../../src/gnc-module:../../../../../src/gnc-module/.libs:../../../../../src/engine:../../../../../src/engine/.libs:../../../../../src/app-utils:../../../../../src/app-utils/.libs:../../../../../src/gnome-utils:../../../../../src/gnome-utils/.libs:../../../../src/gnome-utils:../../../../src/gnome-utils/.libs:../../../../src/network-utils:../../../../src/network-utils/.libs:../../../../src/gnome:../../../../src/gnome/.libs:/usr/lib:/us!
 r/lib/.libs LTDL_LIBRARY_PATH=${LTDL_LIBRARY_PATH}:../../../../src/cor
e-utils:../../../../src/core-utils/.libs:../../../../src/gnc-module:../../../../src/gnc-module/.libs:../../../../src/engine:../../../../src/engine/.libs:../../../../src/app-utils:../../../../src/app-utils/.libs:../../../../src/import-export:../../../../src/import-export/.libs:../../../../src/import-export/qif:../../../../src/import-export/qif/.libs:../../../../src/calculation:../../../../src/calculation/.libs:../../../../src/gnome-utils:../../../../src/gnome-utils/.libs:../../../../../src/gnc-module:../../../../../src/gnc-module/.libs:../../../../../src/engine:../../../../../src/engine/.libs:../../../../../src/app-utils:../../../../../src/app-utils/.libs:../../../../../src/gnome-utils:../../../../../src/gnome-utils/.libs:../../../../src/gnome-utils:../../../../src/gnome-utils/.libs:../../../../src/network-utils:../../../../src/network-utils/.libs:../../../../src/gnome:../../../../src/gnome/.libs:/usr/lib:/usr/lib/.libs ${dir}$tst

FAIL: test-qif
===================
1 of 2 tests failed
===================
make[7]: *** [check-TESTS] Error 1
make[7]: Leaving directory
`/home/chris/cvs/gnucash-test2/gnucash-1.9.0/_build/src/import-export/qif/test'
make[6]: *** [check-am] Error 2

on x86 I get,

make[3]: Entering directory
`/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/po'
INTLTOOL_EXTRACT=../intltool-extract srcdir=../../po ../intltool-update
--gettext-package gnucash --pot
can't
open ../../po/../src/gnome/schemas/apps_gnucash_dialog_scheduled_transctions.schemas.in: No such file or directory at ../intltool-extract line 204.
/usr/bin/xgettext: error while opening
"../../po/../src/backend/dwi/qofmap.c" for reading: No such file or
directory
ERROR: xgettext failed to generate PO template file. Please consult
       error message above if there is any.
make[3]: *** [gnucash.pot] Error 1
make[3]: Leaving directory
`/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/po'
make[2]: *** [check-recursive] Error 1



On Mon, 2006-01-30 at 16:03 +0100, Christian Stimming wrote:

> Hi Chris,
>
> Chris Lyttle schrieb:
> > make[4]: Entering directory
> > `/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/src/doc/design'
> > TEXINPUTS="../../../../src/doc/design:$TEXINPUTS" \
> > MAKEINFO='/bin/sh /home/chris/cvs/gnucash-test/gnucash-1.9.0/missing
> > --run makeinfo   -I ../../../../src/doc/design' \
> > texi2dvi ../../../../src/doc/design/gnucash-design.texinfo
> > This is e-TeX, Version 3.141592-2.2 (Web2C 7.5.5)
> > I can't find the format file `etex.fmt'!
> > kpathsea: Running mktexfmt etex.fmt
> > tcfmgr: config file `tcfmgr.map' (usually in $TEXMFMAIN/texconfig) not
> > found.
> > fmtutil: config file `fmtutil.cnf' not found.
> > /usr/bin/texi2dvi: texinfo.tex appears to be broken, quitting.
>
> Your texinfo and/or tetex installation seems to have a problem. These
> distcheck errors haven't been reported in the near past. Seems to me a
> local problem at your machine?
>
> $ find /usr/share/tex* -name tcfmgr.map
> /usr/share/texmf/texconfig/tcfmgr.map
> $ find /usr/share/tex* -name fmtutil.cnf
> /usr/share/texmf/web2c/fmtutil.cnf
> $ rpm -qf /usr/share/texmf/texconfig/tcfmgr.map
> /usr/share/texmf/web2c/fmtutil.cnf
> tetex-3.0-13
> tetex-3.0-13
>
> I'd propose that we still go for it, today.
> http://wiki.gnucash.org/wiki/Release_Schedule  and
> http://wiki.gnucash.org/wiki/Announcement_1.9.0
>
> Christian
>
--
RedHat Certified Engineer #807302549405490.
Checkpoint Certified Security Expert 2000 & NG
--------------------------------------------
        |^|
        | |   |^|
        | |^| | |  Life out here is raw
        | | |^| |  But we will never stop
        | |_|_| |  We will never quit
        | / __> |  cause we are Metallica
        |/ /    |
        \       /
         |     |
--------------------------------------------


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: tarball POTFILE.in errors; 1.9.0 next Sunday proposed (was: Proposal: Release 1.9.0 today)

Christian Stimming
Ok,

there are obviously still build problems in a tarball. I propose to plan
for a 1.9.0 next Sunday. Until then, everyone should at least once do a
"make dist" and try to compile the resulting tarball from the tarball alone.

Chris Lyttle schrieb:
> on amd64 I get,

Does anyone of the active developers have a amd64 machine at hand? (I
don't.) I would certainly believe that some tests will fail on amd64 as
long as this is none of our actively developed target platforms...

> on x86 I get,
>
> make[3]: Entering directory
> `/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/po'
> INTLTOOL_EXTRACT=../intltool-extract srcdir=../../po ../intltool-update
> --gettext-package gnucash --pot
> can't
> open ../../po/../src/gnome/schemas/apps_gnucash_dialog_scheduled_transctions.schemas.in: No such file or directory at ../intltool-extract line 204.
> /usr/bin/xgettext: error while opening
> "../../po/../src/backend/dwi/qofmap.c" for reading: No such file or
> directory
> ERROR: xgettext failed to generate PO template file. Please consult
>        error message above if there is any.
> make[3]: *** [gnucash.pot] Error 1
> make[3]: Leaving directory
> `/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/po'
> make[2]: *** [check-recursive] Error 1

*sigh* Now this is the generated po/POTFILES.in striking back. There are
obviously some files in SVN that don't make it into the tarball and
nobody noticed so far. The generated po/POTFILES.in cannot distinguish
those from the correct ones. Both
src/gnome/schemas/apps_gnucash_dialog_scheduled_transctions.schemas.in
and src/backend/dwi/qofmap.c are not included in the dist target, but
are included into POTFILES.in by make-gnucash-potfiles because they are
found in a SVN checkout.

(I wonder why the rule for po/gnucash.pot triggers at all -- it
shouldn't in the tarball. But anyway, it should be allowed to call this
rule in the tarball, so POTFILES.in needs to be fixed.)

Here's what we can do:

  #1. Include po/POTFILES.in into SVN again; don't let it be generated
automatically, but only on the manual rule "make pot"; remove those
non-distributed files from the SVN version of POTFILES.in. Problem solved.

  #2. Add those non-distributed files into the @ignorepatterns in
make-gnucash-potfiles. This will fix this particular error from the
generates POTFILES.in.

  #3. Add some wonderful magic into make-gnucash-potfiles which will be
able to tell apart the non-distributed files from the distributed ones.

I can't imagine any implementation of #3 that doesn't involve adding an
extra rule to *all* Makefiles. Has something of "mit Kanonen auf Spatzen
schie├čen", literally "Shoot sparrows by a cannon", in english "to break
a butterfly on a wheel". So either #1 or #2.

Note that eventually #2 isn't any different from having the POTFILES.in
directly in SVN, #1. It is still possible that someone removes a file
from the dist target but leaves it in SVN, which will break the #2
solution, BUT (and that's the not-so-good part) only in the tarball and
not in the normal SVN build, which means this breakage won't be
discovered until the release manager tests the tarballs. :-(

Also a problem of the #2 solution is that it is much more subtle and
less clear how to fix such files that should not be added to
POTFILES.in. The #1 solution OTOH makes it extremely clear how to fix
such files, it will show the build errors directly in the SVN build
which is where it should also be fixed, and it enables the translation
manager (myself) to edit this file into a form that will really include
only those files that contain translations.

I propose #1, adding po/POTFILES.in back into SVN and having it
regenerated only on the manual "make pot" rule.

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: tarball POTFILE.in errors; 1.9.0 next Sunday proposed (was: Proposal: Release 1.9.0 today)

Chris Shoemaker
On Wed, Feb 01, 2006 at 10:56:24AM +0100, Christian Stimming wrote:

> >
> >make[3]: Entering directory
> >`/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/po'
> >INTLTOOL_EXTRACT=../intltool-extract srcdir=../../po ../intltool-update
> >--gettext-package gnucash --pot
> >can't
> >open
> >../../po/../src/gnome/schemas/apps_gnucash_dialog_scheduled_transctions.schemas.in: No such file or directory at ../intltool-extract line 204.
> >/usr/bin/xgettext: error while opening
> >"../../po/../src/backend/dwi/qofmap.c" for reading: No such file or
> >directory
> >ERROR: xgettext failed to generate PO template file. Please consult
> >       error message above if there is any.
> >make[3]: *** [gnucash.pot] Error 1
> >make[3]: Leaving directory
> >`/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/po'
> >make[2]: *** [check-recursive] Error 1
>
> *sigh* Now this is the generated po/POTFILES.in striking back. There are
> obviously some files in SVN that don't make it into the tarball and
> nobody noticed so far. The generated po/POTFILES.in cannot distinguish
> those from the correct ones. Both
> src/gnome/schemas/apps_gnucash_dialog_scheduled_transctions.schemas.in
> and src/backend/dwi/qofmap.c are not included in the dist target, but
> are included into POTFILES.in by make-gnucash-potfiles because they are
> found in a SVN checkout.
>
> (I wonder why the rule for po/gnucash.pot triggers at all -- it
> shouldn't in the tarball. But anyway, it should be allowed to call this
> rule in the tarball, so POTFILES.in needs to be fixed.)
>
> Here's what we can do:
>
>  #1. Include po/POTFILES.in into SVN again; don't let it be generated
> automatically, but only on the manual rule "make pot"; remove those
> non-distributed files from the SVN version of POTFILES.in. Problem solved.
>
>  #2. Add those non-distributed files into the @ignorepatterns in
> make-gnucash-potfiles. This will fix this particular error from the
> generates POTFILES.in.
>
>  #3. Add some wonderful magic into make-gnucash-potfiles which will be
> able to tell apart the non-distributed files from the distributed ones.
>

What about:
   #4. Any source file we version control but don't distribute, we
also don't want to translate.  According to intltool-update, those
files should be listed in POTFILES.skip.  This makes the --maintain
mode of intltool-update more useful.  And, the only magic needed in
make-gnucash-potfiles is "ignore the files listed in POTFILES.skip."

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

RE: tarball POTFILE.in errors; 1.9.0 next Sunday proposed (was: Proposal: Release 1.9.0 today)

Englisch, Volker (NIH/NCI)
In reply to this post by Christian Stimming
> Does anyone of the active developers have a amd64 machine at hand? (I
> don't.) I would certainly believe that some tests will fail on amd64
as
> long as this is none of our actively developed target platforms...

I'm not an active developer but I do have an AMD64 running FC4 sitting
at
home.  I would be willing to create a user account for a developer to do
whatever you need to do.

Thanks

Volker Englisch
mailto:[hidden email]



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: tarball POTFILE.in errors; 1.9.0 next Sunday proposed (was: Proposal: Release 1.9.0 today)

Tim Wunder (Lists)
In reply to this post by Christian Stimming
On Wednesday 01 February 2006 4:56 am, someone claiming to be Christian
Stimming wrote:
> Ok,
>
> there are obviously still build problems in a tarball. I propose to plan
> for a 1.9.0 next Sunday. Until then, everyone should at least once do a
> "make dist" and try to compile the resulting tarball from the tarball
> alone.
>

FWIW, make dist on r13064 results in a tarball that I can untar, configure,
make and make install without problems...

Tim

--
Fedora Core release 4 (Stentz), Linux 2.6.14-1.1656_FC4
KDE: 3.5.1-1.2.fc4.kde, xorg-x11-6.8.2-37.FC4.49.2
 11:10:06 up 10 days,  1:56,  1 user,  load average: 1.02, 1.06, 1.22
MP3/OGG archive Total playlength : 7 days, 19 hours, 54 mins 42 seconds
"It's what you learn after you know it all that counts" John Wooden

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Release 1.9.0 today

Derek Atkins
In reply to this post by Chris Lyttle
Chris Lyttle <[hidden email]> writes:

> OK I managed to get past the tex problem. Was a bug in the 3.0 version,
> downgrading fixed it. I'm still unable to get a compile to work tho;
>
> on amd64 I get,
>
> qif loading
> "../../../../../src/import-export/qif/test/test-files/test-1-bank-txn.qif"...
> *** glibc detected *** double free or corruption (fasttop):
> 0x000000000054dea0 ***
> /bin/sh: line 1: 27224 Aborted

Well, I /suppose/ we could just disable this directory for 1.9.0 --
I never finished the qif importer re-write, so this code isn't being
used.

[snip]

> on x86 I get,
>
> make[3]: Entering directory
> `/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/po'
> INTLTOOL_EXTRACT=../intltool-extract srcdir=../../po ../intltool-update
> --gettext-package gnucash --pot
> can't
> open ../../po/../src/gnome/schemas/apps_gnucash_dialog_scheduled_transctions.schemas.in: No such file or directory at ../intltool-extract line 204.
> /usr/bin/xgettext: error while opening
> "../../po/../src/backend/dwi/qofmap.c" for reading: No such file or
> directory
> ERROR: xgettext failed to generate PO template file. Please consult
>        error message above if there is any.
> make[3]: *** [gnucash.pot] Error 1
> make[3]: Leaving directory
> `/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/po'
> make[2]: *** [check-recursive] Error 1

Hmm, this is interesting..  It's due to the fact that we have code
in SVN that we don't distribute.  We need some way to ignore those
files when we build the POTFILES.

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: tarball POTFILE.in errors; 1.9.0 next Sunday proposed (was: Proposal: Release 1.9.0 today)

Chris Shoemaker
In reply to this post by Chris Shoemaker
On Wed, Feb 01, 2006 at 09:37:20AM -0500, Chris Shoemaker wrote:
> What about:
>    #4. Any source file we version control but don't distribute, we
> also don't want to translate.  According to intltool-update, those
> files should be listed in POTFILES.skip.  This makes the --maintain
> mode of intltool-update more useful.  And, the only magic needed in
> make-gnucash-potfiles is "ignore the files listed in POTFILES.skip."

BTW, this is independent of whether POTFILES.in is under version
control or not.  Either way, it's still generated, and we don't want
to remove obsolete files from the generated POTFILES.in by hand
everytime.

If the generated file is in SVN or if it's not, either way,
make-gnucash-potfiles shouldn't output files we don't want to
translate.

Sanity checking the contents of POTFILES.in in the distcheck-hook also
makes sense either way.  Now, if someone removes a file from dist
without removing it from svn or marking it obsolete in POTFILES.skip,
it will cause make distcheck to fail, well before the tarball is
built.  This actually makes sense because the problem would only show
up in the tarball, not when building from svn.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
12