OK We are good on amd64 now;
===
gnucash-1.9.0 archives ready for distribution:
gnucash-1.9.0.tar.gz
===
I expect it will be the same on my stable x86 box too. I'll keep testing
builds during the week to make s
there is no directory by that name sorry to put you through ...
ls -l /opt/gnucash/share/gnucash/guile-modules/www
ls: /opt/gnucash/share/gnucash/guile-modules/www: No such file or directory
i will retry to build thanks and will be asking you for more help if it didn't work next build
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
In that case why would you have the strings marked for translation?
I can't imagine you'd have a report that says (N_ "¿Donde esta el baño?")
if it's already translated and specific to a particular locale. If all
the strings are pure strings then the
On Wed, Feb 01, 2006 at 04:55:16PM -0500, Derek Atkins wrote:
> Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>
> >I imagine in _theory_ we might _want_ to distribute a file that we
> >explicitly don't want to mark for translation. Like maybe an
> >already-translated report that generates output o
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
I imagine in _theory_ we might _want_ to distribute a file that we
explicitly don't want to mark for translation. Like maybe an
already-translated report that generates output only valid in that one
language?
In that case why would you have the str
On Wed, Feb 01, 2006 at 03:50:24PM -0500, Derek Atkins wrote:
> Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
>
> >dist-hook: po/POTFILES.in
> >
> >-distcheck-hook: po/POTFILES.in
> >+distcheck-hook:
> >+@e=''; \
> >+for X in `grep -v \# ${distdir}/po/POTFILES.in` ; do \
> >+if
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 i
Quoting Chris Shoemaker <[EMAIL PROTECTED]>:
dist-hook: po/POTFILES.in
-distcheck-hook: po/POTFILES.in
+distcheck-hook:
+ @e=''; \
+ for X in `grep -v \# ${distdir}/po/POTFILES.in` ; do \
+ if [ ! -f ${distdir}/$$X ] ; then \
+ echo $$X " is in PO
Chris Lyttle <[EMAIL PROTECTED]> 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"
Pawan Chitrakar <[EMAIL PROTECTED]> writes:
> Thanks for suggestion
>
> but there is no folder by the name www
>
> and out put of the
> 'echo $GUILE_LOAD_PATH'
>
> /usr/share/guile:/opt/gnucash/share/gnucash/guile-modules:/opt/gnucash/share/
> gnucash/scm:
run: ls -l /opt/gnucash/share/gnucash/
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 tarbal
Derek Atkins schrieb:
Previously in cases like this we'd dome something like:
_("placeholder account:P")+20
to represent this.
Yes, we had that, and 80% of the translators messed it up in the first
round, and 40% still in the second round.
I'll note that [2] has the similar restricti
On Wednesday 01 February 2006 16:33, Christian Stimming wrote:
> FTR: We didn't recomment to wildly revert something. When someone says
> "you probably have a svn conflict", you need to find out which file has
> these conflicts. Instead of using some unspecified "svn revert", you are
> instead supp
Eildert Groeneveld schrieb:
This is clearly an SVN merge issue. Are you sure you reverted the
correct file?
then I am sure I did it wrong: in the gnucash-svn directory I issued:
svn revert .
After that - just to make sure - ran
FTR: We didn't recomment to wildly revert something. When s
On Wednesday 01 February 2006 16:13, Derek Atkins wrote:
> This is clearly an SVN merge issue. Are you sure you reverted the
> correct file? It's unclear to me that "svn revert" by itself
> is recursive, so what exact command did you run? Did you then run
> a "make install" after you reverted?
Quoting Christian Stimming <[EMAIL PROTECTED]>:
Derek Atkins schrieb:
Previously in cases like this we'd dome something like:
_("placeholder account:P")+20
to represent this. Then we add a translator note that they only translate
the string to the right of the colon, and leave the left-han
Derek Atkins schrieb:
Previously in cases like this we'd dome something like:
_("placeholder account:P")+20
to represent this. Then we add a translator note that they only translate
the string to the right of the colon, and leave the left-hand side alone.
Yes, we had that, and 80% of the t
On Wed, 2006-02-01 at 09:58 -0500, Derek Atkins wrote:
> Previously in cases like this we'd dome something like:
>
> _("placeholder account:P")+20
>
> to represent this. Then we add a translator note that they only translate
> the string to the right of the colon, and leave the left-hand side
Quoting Eildert Groeneveld <[EMAIL PROTECTED]>:
On Wednesday 01 February 2006 11:34, Eildert Groeneveld wrote:
Backtrace:
In unknown file:
?: 0* [primitive-load-path "report.scm"]
?: 1* <<<
: In expression <<<:
: Unbound variable: <<<
Anybody there who can shed light onto t
On Wednesday 01 February 2006 11:34, Eildert Groeneveld wrote:
>
> Backtrace:
> In unknown file:
>?: 0* [primitive-load-path "report.scm"]
>?: 1* <<<
>
> : In expression <<<:
> : Unbound variable: <<<
>
> Anybody there who can shed light onto this issue?
>
> my revision: 13064
> 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.
Previously in cases like this we'd dome something like:
_("placeholder account:P")+20
to represent this. Then we add a translator note that they only translate
the string to the right of the colon, and leave the left-hand side alone.
-derek
Quoting Christian Stimming <[EMAIL PROTECTED]>:
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
> >../../p
Thanks for suggestion
but there is no folder by the name www
and out put of the
'echo $GUILE_LOAD_PATH'
/usr/share/guile:/opt/gnucash/share/gnucash/guile-modules:/opt/gnucash/share/gnucash/scm:
i am using gnome terminal
command line is ./gnucash in the /opt/gnucash/bin
hope this helps to ide
Hi,
Eildert Groeneveld schrieb:
Backtrace:
In unknown file:
?: 0* [primitive-load-path "report.scm"]
?: 1* <<<
: In expression <<<:
: Unbound variable: <<<
you almost surely have an SVN conflict here. "svn revert" will do the trick.
Christian
___
Hello Folks
some time ago there was discussion on the slib problems in Debian unstable.
It was the conclusion, that downgrading to slib_3a1-4.2_all.deb
would do the trick. This did in deed work. Only after another upgrade gnucash
also worked (at least for me) with the slib_3a2-5_all.deb
Oddly en
Hi Andreas,
Andreas Köhler schrieb:
tree-column-i18n.patch
this one switches the i18n from column headers in tree views from
N_() + gettext to just _(). It seems this is a leftover from old
structures that could not be defined via a function call (or
something like this).
both patches look g
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
Hi,
I attached two files:
> tree-column-i18n.patch
this one switches the i18n from column headers in tree views from
N_() + gettext to just _(). It seems this is a leftover from old
structures that could not be defined via a function call (or
something like this).
It also introduces the transl
29 matches
Mail list logo
