Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Op 23-02-13 05:52, John Ralls schreef: On Feb 22, 2013, at 11:14 AM, Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 19:45, Geert Janssens schreef: Op 22-02-13 19:23, Mike Evans schreef: Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure it that makes any difference. Anyway now we know where the problem is (me) I know the solution is local. Enough for today though I think. My git version is git-1.8.1.2-1.fc18.i686 on Fedora 18. I don't know if that makes a difference or not. What exact url are you using to clone from github ? Mine is g...@github.com:Gnucash/gnucash.git Any other devs seeing this ? Geert Additionally, can you check if the eol attribute is already supported in your git version ? It is mentioned in man gitattributes on my system and is the attribute I'm using to force consistent line endings. It may be a more recent addition. Yeah, I see it on OSX. When I follow the renormalizing procedure, I get warning: CRLF will be replaced by LF in src/report/jqplot/foo.js. The file will have its original line endings in your working directory. For all of the files that Mike listed. Curiously, changing the *.js entry in .gitattributes to crlf and repeating the procedure has no effect. It appears that you got those js files into the repo with crlf line endings. git version 1.7.9.6 (Apple Git-31.1) The eol attribute is documented in gitattributes(5) Regards, John Ralls Ok, that is very likely. Can you or Mike check in the proper conversions ? They don't show up on my system (which I don't understand why that is). Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
On Sat, 23 Feb 2013 10:19:25 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 23-02-13 05:52, John Ralls schreef: On Feb 22, 2013, at 11:14 AM, Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 19:45, Geert Janssens schreef: Op 22-02-13 19:23, Mike Evans schreef: Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure it that makes any difference. Anyway now we know where the problem is (me) I know the solution is local. Enough for today though I think. My git version is git-1.8.1.2-1.fc18.i686 on Fedora 18. I don't know if that makes a difference or not. What exact url are you using to clone from github ? Mine is g...@github.com:Gnucash/gnucash.git Any other devs seeing this ? Geert Additionally, can you check if the eol attribute is already supported in your git version ? It is mentioned in man gitattributes on my system and is the attribute I'm using to force consistent line endings. It may be a more recent addition. Yeah, I see it on OSX. When I follow the renormalizing procedure, I get warning: CRLF will be replaced by LF in src/report/jqplot/foo.js. The file will have its original line endings in your working directory. For all of the files that Mike listed. Curiously, changing the *.js entry in .gitattributes to crlf and repeating the procedure has no effect. It appears that you got those js files into the repo with crlf line endings. git version 1.7.9.6 (Apple Git-31.1) The eol attribute is documented in gitattributes(5) Regards, John Ralls Ok, that is very likely. Can you or Mike check in the proper conversions ? They don't show up on my system (which I don't understand why that is). Geert OK checked in as r22808 4317a28b55655 Mike E -- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Op 23-02-13 11:35, Mike Evans schreef: On Sat, 23 Feb 2013 10:19:25 +0100 Geert Janssens janssens-ge...@telenet.be wrote: Op 23-02-13 05:52, John Ralls schreef: On Feb 22, 2013, at 11:14 AM, Geert Janssens janssens-ge...@telenet.be wrote: Op 22-02-13 19:45, Geert Janssens schreef: Op 22-02-13 19:23, Mike Evans schreef: Thanks for checking Geert. I removed my $HOME/.gitconfig and tried again with the same result. My git version is 1.7.6.5 on Fedora 15 not sure it that makes any difference. Anyway now we know where the problem is (me) I know the solution is local. Enough for today though I think. My git version is git-1.8.1.2-1.fc18.i686 on Fedora 18. I don't know if that makes a difference or not. What exact url are you using to clone from github ? Mine is g...@github.com:Gnucash/gnucash.git Any other devs seeing this ? Geert Additionally, can you check if the eol attribute is already supported in your git version ? It is mentioned in man gitattributes on my system and is the attribute I'm using to force consistent line endings. It may be a more recent addition. Yeah, I see it on OSX. When I follow the renormalizing procedure, I get warning: CRLF will be replaced by LF in src/report/jqplot/foo.js. The file will have its original line endings in your working directory. For all of the files that Mike listed. Curiously, changing the *.js entry in .gitattributes to crlf and repeating the procedure has no effect. It appears that you got those js files into the repo with crlf line endings. git version 1.7.9.6 (Apple Git-31.1) The eol attribute is documented in gitattributes(5) Regards, John Ralls Ok, that is very likely. Can you or Mike check in the proper conversions ? They don't show up on my system (which I don't understand why that is). Geert OK checked in as r22808 4317a28b55655 Mike E Thanks. Git is still happy on my system with the new commit and after renormalizing. So hopefully we fixed it properly this time. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Lot transfers
Dear Peter, I think the fact that there was no reply concerning your ideas and technical details means there currently isn't any interested developer available for working in this field. Given the nature of this volunteer project, unfortunately this means there is only very little chance for you to get this implemented in the near future. Occasionally, there are developers around who are available for paid work on features they don't need personally, but this would involve significantly higher rates that what you mentioned, so it probably won't help you here either. But in general development happens here only if there is at least one developer with a personal interest in the actual feature, which unfortunately doesn't seem to be the case here. Sorry for this not-so-encouraging reply from me. Best Regards, Christian Am Donnerstag, 21. Februar 2013, 23:21:08 schrieb Peter Dey: Just thought I'd followup on this -- I didn't receive any replies. Any idea about the technical complexity involved in implementing this functionality/modification? Thanks, Peter On Wed, Jan 23, 2013 at 10:52:03PM +1100, Peter Dey wrote: Hi all, I've got a bit over AU$100 credit leftover at a freelance developer site called freelancer.com. I'd like to create a project on the site to fund the implementation of the lot transfer functionality described here: http://wiki.gnucash.org/wiki/Concept_of_Lots Since I know very little about GnuCash's internal architecture, I was hoping someone here would be willing to help me write the specification to ensure it's done in a way suitable to be merged into the mainline, for everyone to benefit from it. As far as I can tell, it would involve: 1. Addition of a checkbox to the New/Edit account screens to mark an account as a lot account 2. A hook somewhere auto-create a new lot when there's a new entry. Code could probably be borrowed from the scrubber? 3. (personal preference, not on the wiki) add a column to lot accounts to show the lot title against every split 4. Assume LIFO like the scrubber does -- add a hook to auto-assign (and close) lots on outgoing transactions. Again,. probably could be borrowed from the lot scrubber. 5. The most complicated: alter the data structure to remove the tie between lots and accounts (i.e., guid only). This will probably need changes in other places that make an assumption or have a dependency that lot guids lie in a single account. I can only think of the lot scrubber at the moment? 6. Assuming it would go into a future release of GnuCash, presumably some logic to upgrade the data file/database schema Any and all help appreciated... Cheers, Peter ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
Am Samstag, 23. Februar 2013, 11:57:18 schrieb Geert Janssens: Additionally, can you check if the eol attribute is already supported in your git version ? It is mentioned in man gitattributes on my system and is the attribute I'm using to force consistent line endings. It may be a more recent addition. I think the easiest way out here (as long as we're still using SVN) is to set the per-file SVN property svn:eol-style to some fixed value (here: LF). This ensures the file get one canonical set of eol markers. However, setting this property requires a client-side action: Either the file ~/.subversion/config needs some manual changes as described here http://stackoverflow.com/questions/5671406/force-svneol-style-native-on- the-server which sets the property at the initial checkin of each file, or we need to do one additional SVN commit to set that property, which I've just done in r22809. Note: For most of our *.h / *.c files I've also done this manually in e.g. r20217 or r18959, which explains why we didn't have any trouble with those files and line endings. I strongly suggest for every developer to modify one's own ~/.subversion/config to set svn:eol-style=LF for *.h, *.c so that we continue with a consistent setting of the line endings. As for git: The gitattributes feature is probably the most closely matching feature of git, related to the svn:eol-style property. Once git-1.8 has been distributed widely enough, we probably will have this problem solved with git's gitattributes file on the git side as well. Until then, we should probably keep an eye on setting svn:eol-style correctly. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bugzilla default/QA assignees
Am Montag, 18. Februar 2013, 17:09:20 schrieb John Ralls: The default assignee field is mostly used to determine who gets bugmail for a particular component. Some of the assignments make sense, like having me be the default for Mac bugs, some not so much, like Chris Shoemaker for budget bugs: He hasn't been around for a long time. It also makes it hard for non-bugzilla-admins to set themselves up for bugmail on new bugs, because the mechanism for doing so is to watch another user. Watching a real user means that you get bug mail not only for the bugs that that user is the default assignee,QA contact, or added to the CC list, but also for every bug that user comments on. Not really useful unless you're a stalker. The mainstream Gnome approach is to have fake users for default assignees; for example, the Gtk Quartz backend has gtk-quartz-ma...@gnome.bugs, which I watch so that I get bug mail for any of those. I propose doing the same for our gnucash components, with a per-component address for default assignee and a gnucash-bugs address for QA assignee to make it easy to get all bugmail. I'll change the components, but I can't create the users because I don't have privs for doing that. +1 on the proposal, absolutely. But I didn't understand who needs to do the next step here. Where do we have to create the users? In bugzilla or as mailing lists on gnucash.org? Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bugzilla default/QA assignees
On Feb 23, 2013, at 8:19 AM, Christian Stimming christ...@cstimming.de wrote: Am Montag, 18. Februar 2013, 17:09:20 schrieb John Ralls: The default assignee field is mostly used to determine who gets bugmail for a particular component. Some of the assignments make sense, like having me be the default for Mac bugs, some not so much, like Chris Shoemaker for budget bugs: He hasn't been around for a long time. It also makes it hard for non-bugzilla-admins to set themselves up for bugmail on new bugs, because the mechanism for doing so is to watch another user. Watching a real user means that you get bug mail not only for the bugs that that user is the default assignee,QA contact, or added to the CC list, but also for every bug that user comments on. Not really useful unless you're a stalker. The mainstream Gnome approach is to have fake users for default assignees; for example, the Gtk Quartz backend has gtk-quartz-ma...@gnome.bugs, which I watch so that I get bug mail for any of those. I propose doing the same for our gnucash components, with a per-component address for default assignee and a gnucash-bugs address for QA assignee to make it easy to get all bugmail. I'll change the components, but I can't create the users because I don't have privs for doing that. +1 on the proposal, absolutely. But I didn't understand who needs to do the next step here. Where do we have to create the users? In bugzilla or as mailing lists on gnucash.org? In Bugzilla, AdministrationUsers I think. The descriptive blurb for users says that one can create users there, but my privs allow me only to search. If no-one here has privs to make the users, I'll file a bug to the bug team to get it done. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
make check fails
Make check fails as follows: Making check in po make[1]: Entering directory `/home/gnucash-dev/svncheckouts/gnucash-clean-build/po' make[1]: *** No rule to make target `/home/gnucash-dev/svncheckouts/gnucash-clean/src/html/gnc-html-graph-gog.c', needed by `gnucash.pot'. Stop. make[1]: Leaving directory `/home/gnucash-dev/svncheckouts/gnucash-clean-build/po' make: *** [check-recursive] Error 1 I know some of you were cleaning up some of the graph reports and eliminating dependencies on goffice. Related? Regards, Alex ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: make check fails
Op 23-02-13 21:28, Alex Aycinena schreef: Make check fails as follows: Making check in po make[1]: Entering directory `/home/gnucash-dev/svncheckouts/gnucash-clean-build/po' make[1]: *** No rule to make target `/home/gnucash-dev/svncheckouts/gnucash-clean/src/html/gnc-html-graph-gog.c', needed by `gnucash.pot'. Stop. make[1]: Leaving directory `/home/gnucash-dev/svncheckouts/gnucash-clean-build/po' make: *** [check-recursive] Error 1 I know some of you were cleaning up some of the graph reports and eliminating dependencies on goffice. Related? Regards, Alex ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Good catch. That was me indeed. Should be fixed in r22812 Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CRLF issues on checkout (was Re: Gnucash 2.5/6 - jqplot)
--On February 23, 2013 5:07:47 PM +0100 Christian Stimming christ...@cstimming.de wrote: I think the easiest way out here (as long as we're still using SVN) is to set the per-file SVN property svn:eol-style to some fixed value (here: LF). This ensures the file get one canonical set of eol markers. However, setting this property requires a client-side action: Either the file ~/.subversion/config needs some manual changes as described here http://stackoverflow.com/questions/5671406/force-svneol-style-native- on- the-server which sets the property at the initial checkin of each file, or we need to do one additional SVN commit to set that property, which I've just done in r22809. Note: For most of our *.h / *.c files I've also done this manually in e.g. r20217 or r18959, which explains why we didn't have any trouble with those files and line endings. I strongly suggest for every developer to modify one's own ~/.subversion/config to set svn:eol-style=LF for *.h, *.c so that we continue with a consistent setting of the line endings. Do you really want to use LF for eol-style for these file types? I would think that native would work better. That's what I've been using for years on various SVN projects and it seems to work well. I don't work on Windows much anymore, but I used to and often worked on the same file on both systems. Native is also what the stackoverflow article you mention suggests. If you specify this eol format then the local file will be in the native format but the repository version will always be with LF line endings. For a discussion of the eol-style property see http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Lot transfers
On Sat, Feb 23, 2013 at 04:46:24PM +0100, Christian Stimming wrote: But in general development happens here only if there is at least one developer with a personal interest in the actual feature, which unfortunately doesn't seem to be the case here. Sorry for this not-so-encouraging reply from me. Thanks for the reply, Christian. I kind of expected this would be the case anyway, but figured it was worth a try! Cheers, Peter ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
