Op vrijdag 21 september 2018 04:13:22 CEST schreef David Cousens:
> Geert
>
> "I think a generic page for autotools based build and one for cmake based
> builds would be useful. We can even consider abandoning the autotools based
> page to save time. This should be accompanied with a page that
Op vrijdag 21 september 2018 01:16:51 CEST schreef David Cousens:
> Adrien,
>
> I think it is better to leave packaging apps to specialists rather than the
> general user.
> Using flatpak and snap can be better addressed on the
> Installation page rather than a building page which also addresses
Geert
"I think a generic page for autotools based build and one for cmake based
builds would be useful. We can even consider abandoning the autotools based
page to save time. This should be accompanied with a page that explains how
to
set up the proper dependencies based on your platform.
Adrien,
I think it is better to leave packaging apps to specialists rather than the
general user. Using flatpak and snap can be better addressed on the
Installation page rather than a building page which also addresses using ,
Software Mmanager and installation of the version supported by the
On Thu, 2018-09-20 at 11:42 -0500, Adrien Monteleone wrote:
> While you’re tweaking this, consider changing the debian/derivative
> instructions to use ‘apt’ instead of ‘apt-get’ as
> my understanding the distro preferences are for the newer ‘apt’ user tool.
> (not to be confused, due to
I was thinking more along the lines of .deb/.rpm but if it adds complexity to
get up and running, certainly, it should not be included. (or perhaps as a
breakout page option)
I don’t take that route for my own installations as I’m more familiar with
building and cleaning up after myself.
Op donderdag 20 september 2018 19:09:10 CEST schreef Adrien Monteleone:
> > On Sep 20, 2018, at 5:46 AM, David Cousens
> > wrote:
> >
> >
> > I'll set the examples up to default to a /home/user/.local install and
> > then perhaps add an extra section on installing for all users and the
> >
> On Sep 20, 2018, at 5:46 AM, David Cousens wrote:
>
>>
> I'll set the examples up to default to a /home/user/.local install and then
> perhaps
> add an extra section on installing for all users and the various options
> there and
> the need for administrator privileges. Most Linux users
While you’re tweaking this, consider changing the debian/derivative
instructions to use ‘apt’ instead of ‘apt-get’ as my understanding the distro
preferences are for the newer ‘apt’ user tool. (not to be confused, due to
unfortunate naming, with the low level ‘apt’)
Regards,
Adrien
> On Sep
>
> Didn't apt-get build-dep gnucash install most of the dependencies already ?
It does , but it installs the dependencies for the version of GnuCash that the
distribution supports in its package management system. I ran into this problem
with 3.0-3.2 where a few libraries were up dated. Can
Op woensdag 19 september 2018 23:51:35 CEST schreef David Cousens:
> John, Geert, Adrien, David
>
> Thanks for all the prespectives. I will attempt a restructure of the
> Building Gnucash page and its derivatives, trying to push as much
> information back to the generic Linux level as I can from
John, Geert, Adrien, David
Thanks for all the prespectives. I will attempt a restructure of the Building
Gnucash page and its derivatives, trying
to push as much information back to the generic Linux level as I can from the
BuildingUbuntu 16.04 pages. I have no
experience of building on Windows
For users to be able to obtain the latest (or otherwise particularly desired)
version not in their repos, I would agree with David C. & Geert here that a
single generic linux recipe for tarballs, augmented with links to quirks for
particular *non-deprecated* distributions and/or historical
On Tue, 2018-09-18 at 13:16 -0400, David T. via gnucash-devel wrote:
> Hello,
>
> I have a general question about building. Forgive me if this is naive. The
> last time I used Linux was last century,
> and I believe that Linux has changed just a tad since then.
>
> Since GnuCash is now
Op dinsdag 18 september 2018 10:19:02 CEST schreef David Cousens:
> John, David, Frank
>
> I wonder at the value of the Build Tools page as a separate orphan entity
> given the more detailed instructions given in the Building Gnucash page.
> There is a fairly good example of dupllcation with it
Op woensdag 19 september 2018 05:19:08 CEST schreef John Ralls:
> It’s Debian and derivatives: Ubuntu is a derivative--or these days maybe a
> symbiote, there are Canonical reps on the Debian board--of Debian.
>
> I frankly don’t understand why Ubuntu needs a per-release explanation of how
> to
It’s Debian and derivatives: Ubuntu is a derivative--or these days maybe a
symbiote, there are Canonical reps on the Debian board--of Debian.
I frankly don’t understand why Ubuntu needs a per-release explanation of how to
build it, especially since Debian doesn’t. `sudo apt-get build-dep
On Tue, 2018-09-18 at 11:18 -0500, Adrien Monteleone wrote:
> > On Sep 18, 2018, at 7:53 AM, Frank H. Ellenberger
> > wrote:
> >
> >
> > Perhaps you can do some cleanup: Is Gutsy outdated?
>
> That was version 7.10 of Ubuntu, that is, released October 2007. By far, it
> is no longer
> On Sep 18, 2018, at 12:16 PM, David T. wrote:
>
>>
>> Along with that, if older material for older systems and versions isn’t
>> going to be moved to its own ‘archive’ page, then it should always appear
>> down the page in chronological order. The current state of the build
>>
Hello,
I have a general question about building. Forgive me if this is naive. The last
time I used Linux was last century, and I believe that Linux has changed just a
tad since then.
Since GnuCash is now developed over git, can't users|developers|writers|yetis
use git for most distros to
> On Sep 18, 2018, at 7:53 AM, Frank H. Ellenberger
> wrote:
>
>
> Perhaps you can do some cleanup: Is Gutsy outdated?
That was version 7.10 of Ubuntu, that is, released October 2007. By far, it is
no longer supported by Canonical. (wasn’t even a Long Term Support release) And
there is
Hi David Cousens,
In general the wiki needs some modularization to reduce redundancy. That
means, where ever you see similar text, create a new page with the best
parts and replace the pold texts with a link.
OTOH there are different target groups from expirienced coders to less
techie first
John, David, Frank
I wonder at the value of the Build Tools page as a separate orphan entity
given the more detailed instructions given in the Building Gnucash page.
There is a fairly good example of dupllcation with it and the following for
the Gnucash progarm build.
John,
Thank you for stepping in. This looks much better now, and I believe I
understand it, maybe. I have added a link to this page from the broader
Documentation Update Instructions page (so it won’t be lonely).
David
> On Sep 17, 2018, at 3:04 PM, John Ralls wrote:
>
>
>
>> On Sep 17,
> On Sep 17, 2018, at 10:49 AM, David T. via gnucash-devel
> wrote:
>
> Frank,
>
>> On Sep 17, 2018, at 12:23 PM, Frank H. Ellenberger
>> wrote:
>>
>> Am 17.09.18 um 17:24 schrieb David T.:
>>>
>>> I worked a bit on Build Tools to make the flow seem more natural; see
>>> whether you
David,
Am 17.09.18 um 19:49 schrieb David T.:
> Frank,
>
>> On Sep 17, 2018, at 12:23 PM, Frank H. Ellenberger
>> wrote:
>>
>> Am 17.09.18 um 17:24 schrieb David T.:
>>>
>>> I worked a bit on Build Tools to make the flow seem more natural; see
>>> whether you agree.
>>
>> I am no fan of
Frank,
> On Sep 17, 2018, at 12:23 PM, Frank H. Ellenberger
> wrote:
>
> Am 17.09.18 um 17:24 schrieb David T.:
>>
>> I worked a bit on Build Tools to make the flow seem more natural; see
>> whether you agree.
>
> I am no fan of "__NOTOC__" because I want often send a deep link (read
>
Am 17.09.18 um 17:24 schrieb David T.:
> Frank,
>
>> On Sep 17, 2018, at 10:47 AM, Frank H. Ellenberger
>> wrote:
>>
>> Hi David,
>>
>> Am 17.09.18 um 14:59 schrieb David T.:
>>> Hello,
>>>
>>> Can anyone give me clear language on when and why a documentation creator
>>> would need to reissue
> On Sep 17, 2018, at 8:24 AM, David T. via gnucash-devel
> wrote:
>
> Frank,
>
>> On Sep 17, 2018, at 10:47 AM, Frank H. Ellenberger
>> wrote:
>>
>> Hi David,
>>
>> Am 17.09.18 um 14:59 schrieb David T.:
>>> Hello,
>>>
>>> Can anyone give me clear language on when and why a
Frank,
> On Sep 17, 2018, at 10:47 AM, Frank H. Ellenberger
> wrote:
>
> Hi David,
>
> Am 17.09.18 um 14:59 schrieb David T.:
>> Hello,
>>
>> Can anyone give me clear language on when and why a documentation creator
>> would need to reissue the commands in Initializing Documentation Build
Hi David,
Am 17.09.18 um 14:59 schrieb David T.:
> Hello,
>
> Can anyone give me clear language on when and why a documentation creator
> would need to reissue the commands in Initializing Documentation Build
> Environment? I’d like to clear this issue up on the wiki before it gets lost.
>
>
Hello,
Can anyone give me clear language on when and why a documentation creator would
need to reissue the commands in Initializing Documentation Build Environment?
I’d like to clear this issue up on the wiki before it gets lost.
David
> On Sep 14, 2018, at 10:21 AM, David T. wrote:
>
>
Frank, Geert,
I am finally following up on this thread, and I’d like to note that the
information that Frank says “got lost,” and which Geert has re-entered on this
page were actually moved to a different page
(https://wiki.gnucash.org/wiki/Initializing_Documentation_Build_Environment
Am 17.08.2018 um 09:18 schrieb Geert Janssens:
> Op vrijdag 17 augustus 2018 08:41:05 CEST schreef David T. via gnucash-devel:
:
>> I’m not sure why there’s a “missing” in the initial command, and I don’t
>> know where config.guess is supposed to be—and I won’t even try to guess.
>>
>> I would
Op vrijdag 17 augustus 2018 08:41:05 CEST schreef David T. via gnucash-devel:
> Hello,
>
> If I am working on updating the documentation, it must be time for me to
> bang my head against some command line hiccup! Yup! Right
> on time.
>
> Following my handy-dandy git cheat sheet, I’ve pulled
For what it’s worth, I was able to dig out the old xmllint/xsltproc commands
and test and view my edits.
I’d still love to know how I’ve f**ked up my development environment so that
the currently-sanctioned approach (make|make clean|make install|make hay while
the sun shines) doesn’t work.
36 matches
Mail list logo