Re: [fossil-users] Linux 2.6 :-(
On Wed, Aug 6, 2014 at 1:29 AM, Warren Young war...@etr-usa.com wrote:
That has more to do with contemporaneity. When you talk about Linux 3.x,
you also necessarily imply recent versions of glibc and such, which is the
true dependency.
+1
I seriously doubt Fossil actually makes any syscalls added to Linux 3.x,
not present in Linux 2.6. (If there are any such calls, they're probably
nonportable.)
Correct. The only system-level APIs we use anywhere (off the top of my
head):
- networking, but those are standard APIs which don't randomly change from
glibc version A to B.
- system(), fork(), exec(), but those are also age-old and don't just
randomly change.
- Windows and (IIRC) Mac: native-to/from-unicode string conversions ('Nix
platforms do not do these).
i'm pretty certain (not 100%) that that's it, but i know we don't use any
Linux-specific calls which might depend on a newer glibc version, except
possibly indirectly via the fuse module (its public API does not expose any
such dependencies, but it almost certainly has low-level deps on the OS).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Linux 2.6 :-(
Or you could ask me, since I wrote autosetup :-) I appreciate your assistance and responsiveness. glob.tcl is bundled up in the jimsh0 executable, but you can find it because the source code is there - autosetup/jimsh0.c Some part of the autosetup/configure process is failing because of these odd permissions. Try running ./configure --debug and look at or send the resulting config.log My guess is that it's not the actual `glob.tcl` file, but rather the path that this program is trying to stat(). It would be nice to drop down to an interactive prompt during debugging and examine the program's state. Since the fossil application is supposed to be self-contained, it seems like it can do its job looking only at the current folder and not have to go elsewhere. But then again, maybe I don't know. swoods@web75:Fossil-e0199bfc43$ ./configure --debug glob.tcl:13: Error: Permission denied in procedure 'main' called at file ./autosetup/autosetup, line 1908 in procedure 'glob' called at file ./autosetup/autosetup, line 123 in procedure 'glob.glob' called at file glob.tcl, line 174 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.globdir' called at file glob.tcl, line 97 at file glob.tcl, line 13 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] A simple thought/idea on the click-to-diff feature
Hi, The idea of just clicking on 2 revisions in the timeline to get a diff is very convenient, but I would like to suggest a small improvement: No matter what order I click the boxes in, it should display the diff from the older to the newer. To me it just makes more sense, since that is what I think is usually wanted. If this seems to much, than maybe at least have a small notice at the top of the diff page if the diff is from a newer to an older revision. Obviously, I am suggesting this since I recently got it backwards and didn't notice at first and was very confused for a few minutes. Baruch -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A simple thought/idea on the click-to-diff feature
On Thu, Aug 7, 2014 at 10:59 AM, Baruch Burstein bmburst...@gmail.com wrote: Hi, The idea of just clicking on 2 revisions in the timeline to get a diff is very convenient, but I would like to suggest a small improvement: No matter what order I click the boxes in, it should display the diff from the older to the newer. I think this is a very bad idea. I often use the 2-click feature to look at diffs between trunk and some branch. I want to know what changes would occur on trunk if I merged the branch into trunk. To do this, I click on the trunk node first, then the branch node. This gives me the correct diff *even if the trunk happens to have the more recent commit*. Your approach would give the wrong diff in that case. Order is important. The standard command-line unix diff command also considers the order of the arguments to be important. It would not be a feature to have unix diff order the difference such that the file with the oldest mtime came first. That would likely drive experienced unix users to violence. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to push to chiselapp
Andy Bradford wrote: Thus said Will Parsons on Thu, 07 Aug 2014 00:53:53 -: Since I wasn't transmitting any sensitive data anyway, I answered yes, and then got: Error: not authorized to write Is there something wrong with the way I'm trying to authenticate? I see you used -B for HTTP_AUTH. I don't know, but does chiselap actually require HTTP_AUTH? At any rate, it won't be used unless required, however, I suspect you are missing the actual Fossil username somewhere and this is why Fossil is telling you that you are not authorized to write. Without a Fossil username, you get the default set of permissions which does not include the permission to write to the repository. I don't understand - what I represented by uname in the command *is* my chiselapp user name. To be clear, in my original local repository, I had a superuser name1. I created the chiselapp user as name2. Looking at the repository on chiselapp, I see two superusers, name1 and name2. name2 is what I represented by uname in the command I indicated. I assume I would have to supply my chiselapp name and password in the command line somehow, and if not by the -B option, then how? You had: fossil push https://chiselapp.com/user/uname/repository/reponame -B 'uname:passwd' Maybe you should try something like the following instead: fossil push https://un...@chiselapp.com/user/uname/repository/reponame Now I'm really confused - what does that have to do with the chiselapp repository? (At any rate, I did try it and got connection refused.) -- Will ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On 8/6/2014 21:00, Andy Bradford wrote: Thus said B Harder on Wed, 06 Aug 2014 10:41:47 -0700: Do we have fine-grained control over pulling only specifically rooted branches? No, but you can certainly clone the developers clone and inspect his changes before pulling into your clone (or pushing directly to main repository). This is beginning to sound like my outside contributions feature request, a.k.a. uber-patch: http://goo.gl/4lLAuY My idea was to allow untrusted outsiders to be able to send a richer patch file than patch(1) allows, but it could also be used for this use case where we want semi-trusted developers to make commits to the repository which are later merged in. I still think drawing that line inside the development team is a bad idea for development cycle time reasons, though. Trust, but verify. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to push to chiselapp
Andy Bradford wrote: Thus said Will Parsons on Thu, 07 Aug 2014 00:53:53 -: fossil push https://chiselapp.com/user/uname/repository/reponame -B 'uname:passwd' By the way, if chiselapp does support HTTP_AUTH, then you might simply need to enable REMOTE_USER support in your respository if that is how you prefer to authenticate. The ``Allow REMOTE_USER authentication'' setting is found under Admin-Access and it should be safe to use as long as you are using HTTPS, otherwise, it's safer to use Fossil authentication. HTTP_AUTH is also safe over HTTP combined with Fossil authentication if the HTTP user/pass are different from the Fossil user/pass. I don't *prefer* to authenticate this way, but I tried it anyway without success. -- Will ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Linux 2.6 :-(
On 8/7/2014 01:26, Stephan Beal wrote: i'm pretty certain (not 100%) that that's it, but i know we don't use any Linux-specific calls which might depend on a newer glibc version, After I posted that, I went out and looked for a list of Linux syscalls that included the point where they were introduced. It turns out that recent versions of syscalls(2) include such a table: http://man7.org/linux/man-pages/man2/syscalls.2.html I went through that list; Fossil has no business using any of the Linux 3.0+ calls. They're kernel module loading enhancements, virtualization improvements, etc. Some of them aren't even exposed by glibc. Not a one is portable, not even by way of cloning a BSD feature. The only thing Fossil *could* really make use of is sendmmsg(2), which for TCP sockets is just a non-portable version of writev(2). It only provides real value for datagram (e.g. UDP) sockets. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Wiki formatting
I have set up a fossil-wiki for my own use. I look at the wiki-editing page and I see controls for some formatting features; fonts, font-size, bolding, indentation, bullets,... These formatting features would be useful to me. However, every time I try to use the formatting features, nothing happens. My current edit-mode is WYSIWYG. Is there something simple I can do to get the formatting to work? I did see the Wiki Formatting Rules but html coding is a vague memory for me and I am hoping to avoid it. I would rather stay with WYSIWYG. Thanks, Wayne Hajas Stock Assessment Analyst Fisheries and Oceans Canada Pacific Biological Station Canada 250-756-7367 wayne.ha...@dfo-mpo.gc.ca ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki formatting
On 8/7/2014 14:20, Hajas, Wayne wrote: every time I try to use the formatting features, nothing happens. Wild guess: you're using a fairly recent version of IE on Windows. You're probably running into Microsoft's brain-dead choice to run all intranet sites in compatibility mode by default. Because /obviously/ all intranet sites in the whole world are tied intimately to IE6 and can never work on anything that doesn't meticulously replicate its particularly sweet set of misfeatures and bugs. For the moment, your best bet is to turn this feature off. If you're in the current version of IE11, click the gear icon in the upper right corner of the window, select Compatibility View Settings, then turn off Display intranet sites in Compatibility View. Now your WYSIWYG buttons should work. The real solution is for Fossil to start sending the X-UA-Compatible HTTP header with the value IE=edge, at least when the browser declares itself to be IE. This tells IE that even though this is an intranet site, it really is compatible with modern browsers. Those of you testing remote Fossils with IE won't have run into this, since now Fossil UI is an Internet site, and so is presumed to be standards-compliant. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Wiki formatting
On 8/7/2014 14:51, Warren Young wrote: On 8/7/2014 14:20, Hajas, Wayne wrote: every time I try to use the formatting features, nothing happens. Wild guess: you're using a fairly recent version of IE on Windows. On re-reading this, I see that my post looks like pure speculation, but it's actually a test report. Fossil is in fact not sending IE=edge, so consequently a default install of IE8+ will treat the site as IE6 or IE7 in compatibility mode. This not only breaks the WYSIWYG wiki editor, it breaks the CSS in my customized version of the khaki skin, and probably other things. I know about it because it bit us on my company's web app, which almost always runs on intranet servers. See http://msdn.microsoft.com/en-us/library/jj676915%28v=vs.85%29.aspx The claims in that article about edge mode being preferred in IE11 doesn't override this default behavior for intranet sites. If setting custom HTTP headers directly is not practical -- can't see why, since Fossil runs its own web server -- you can use a meta tag to do the same thing, as shown in the MSDN article. In fact, that might be required in the SCGI case; haven't tried it. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A simple thought/idea on the click-to-diff feature
Thus said Baruch Burstein on Thu, 07 Aug 2014 17:59:08 +0300: The idea of just clicking on 2 revisions in the timeline to get a diff is very convenient, but I would like to suggest a small improvement: No matter what order I click the boxes in, it should display the diff from the older to the newer. Personally, I like the current behavior. I determine the order in which I want the output to look based upon the order of the clicking of the boxes. Seems natural. Maybe a ``reverse order'' button when viewing the diff would be useful though? Just my 2c. Andy -- TAI64 timestamp: 400053e3f5a8 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A simple thought/idea on the click-to-diff feature
On Thu, Aug 7, 2014 at 11:54 PM, Andy Bradford amb-fos...@bradfords.org wrote: Personally, I like the current behavior. I determine the order in which agreed, but.. Seems natural. Maybe a ``reverse order'' button when viewing the diff would be useful though? See the Invert button. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
Thus said Warren Young on Thu, 07 Aug 2014 13:50:18 -0600: This is beginning to sound like my outside contributions feature request, a.k.a. uber-patch: http://goo.gl/4lLAuY Yes, it is, and I had that same thought as I typed it, but, it can already be accomplished with Fossil clone to some extent. :-) Of course for a big repository this won't work very well (unless one doesn't discard the developers clone and just does a pull when needed). But clearly not meant to replace your ``uber-patch'' idea (which just needs someone to find some time to make it). Thanks, Andy -- TAI64 timestamp: 400053e3f79f ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On Thu, Aug 7, 2014 at 3:50 PM, Warren Young war...@etr-usa.com wrote: This is beginning to sound like my outside contributions feature request, a.k.a. uber-patch: http://goo.gl/4lLAuY My idea was to allow untrusted outsiders to be able to send a richer patch file than patch(1) allows, but it could also be used for this use case where we want semi-trusted developers to make commits to the repository which are later merged in. I still think drawing that line inside the development team is a bad idea for development cycle time reasons, though. Trust, but verify. Many corporate software teams use high ceremony VCSs like Synergy CM and Perforce because such systems can impose role based limitations. While this is usually driven by management, software developers who have worked with such systems often end up preferring having those limitations imposed by the VCS. My team does not. Sometimes we do forget to create a fix/feature branch, but commits can be moved after-the-fact. Most times we catch this immediately. Very, very rarely more than a day. And certainly well before a release. While I can think of an enhancement to the private branch handling that help prevent accidental pushes to trunk, or other designated branches, I don't see the benefit outweighing the costs. An Enterprise Fossil could be created either as a wrapping around Fossil or as a libfossil based application. My team doesn't need that, so I don't expect I would do that, but I am willing to share my thoughts with anyone who might want to implement that. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A simple thought/idea on the click-to-diff feature
Thus said Stephan Beal on Thu, 07 Aug 2014 23:59:23 +0200: Seems natural. Maybe a ``reverse order'' button when viewing the diff would be useful though? See the Invert button. Well... ok then, I will! It's nice when something already exists. :-) Thanks, Andy -- TAI64 timestamp: 400053e3f8df ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Linux 2.6 :-(
On 8 Aug 2014, at 12:52 am, Sean Woods s...@seanwoods.com wrote: Or you could ask me, since I wrote autosetup :-) I appreciate your assistance and responsiveness. glob.tcl is bundled up in the jimsh0 executable, but you can find it because the source code is there - autosetup/jimsh0.c Some part of the autosetup/configure process is failing because of these odd permissions. Try running ./configure --debug and look at or send the resulting config.log My guess is that it's not the actual `glob.tcl` file, but rather the path that this program is trying to stat(). It would be nice to drop down to an interactive prompt during debugging and examine the program's state. Since the fossil application is supposed to be self-contained, it seems like it can do its job looking only at the current folder and not have to go elsewhere. But then again, maybe I don't know. swoods@web75:Fossil-e0199bfc43$ ./configure --debug glob.tcl:13: Error: Permission denied in procedure 'main' called at file ./autosetup/autosetup, line 1908 in procedure 'glob' called at file ./autosetup/autosetup, line 123 in procedure 'glob.glob' called at file glob.tcl, line 174 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.globdir' called at file glob.tcl, line 97 at file glob.tcl, line 13 Thanks. Looks like this commit (https://github.com/msteveb/jimtcl/commit/7bf43eb589f738b7bdb3b4837bc0dde304046a2d) means that Jim Tcl now requires read access to each element of the path. I'll take a look at fixing this. In the meantime, you can install Tcl (and remove autosetup/jimsh0), or change the permissions. Cheers, Steve -- Embedded Systems Specialists - http://workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Linux 2.6 :-(
On 8 Aug 2014, at 10:58 am, Steve Bennett ste...@workware.net.au wrote: On 8 Aug 2014, at 12:52 am, Sean Woods s...@seanwoods.com wrote: Or you could ask me, since I wrote autosetup :-) I appreciate your assistance and responsiveness. glob.tcl is bundled up in the jimsh0 executable, but you can find it because the source code is there - autosetup/jimsh0.c Some part of the autosetup/configure process is failing because of these odd permissions. Try running ./configure --debug and look at or send the resulting config.log My guess is that it's not the actual `glob.tcl` file, but rather the path that this program is trying to stat(). It would be nice to drop down to an interactive prompt during debugging and examine the program's state. Since the fossil application is supposed to be self-contained, it seems like it can do its job looking only at the current folder and not have to go elsewhere. But then again, maybe I don't know. swoods@web75:Fossil-e0199bfc43$ ./configure --debug glob.tcl:13: Error: Permission denied in procedure 'main' called at file ./autosetup/autosetup, line 1908 in procedure 'glob' called at file ./autosetup/autosetup, line 123 in procedure 'glob.glob' called at file glob.tcl, line 174 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.glob' called at file glob.tcl, line 85 in procedure 'glob.globdir' called at file glob.tcl, line 97 at file glob.tcl, line 13 Thanks. Looks like this commit (https://github.com/msteveb/jimtcl/commit/7bf43eb589f738b7bdb3b4837bc0dde304046a2d) means that Jim Tcl now requires read access to each element of the path. I'll take a look at fixing this. In the meantime, you can install Tcl (and remove autosetup/jimsh0), or change the permissions. I have fixed Jim Tcl, updated autosetup, and pushed a new version to the 'autosetup' branch. Please test. If it looks ok, perhaps someone can pull it into trunk. Cheers, Steve -- Embedded Systems Specialists - http://workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Linux 2.6 :-(
I have fixed Jim Tcl, updated autosetup, and pushed a new version to the 'autosetup' branch. Please test. If it looks ok, perhaps someone can pull it into trunk. Woo hoo! It works! Bonzer!! swoods@web75:Fossil-93fb7c774f$ ./fossil version This is fossil version 1.25 [93fb7c774f] 2014-08-08 02:26:54 UTC ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Linux 2.6 :-(
Thus said Steve Bennett on Fri, 08 Aug 2014 12:30:52 +1000: I have fixed Jim Tcl, updated autosetup, and pushed a new version to the 'autosetup' branch. Did you intend for the branch to split off of such an old revision of trunk? Thanks, Andy -- TAI64 timestamp: 400053e44780 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Linux 2.6 :-(
On 8 Aug 2014, at 1:43 pm, Andy Bradford amb-sendok-1410061405.efmchampahhhjobco...@bradfords.org wrote: Thus said Steve Bennett on Fri, 08 Aug 2014 12:30:52 +1000: I have fixed Jim Tcl, updated autosetup, and pushed a new version to the 'autosetup' branch. Did you intend for the branch to split off of such an old revision of trunk? No. Not sure why that happened. I'm out of practice with fossil. -- Embedded Systems Specialists - http://workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Linux 2.6 :-(
Thus said Steve Bennett on Fri, 08 Aug 2014 14:00:02 +1000: No. Not sure why that happened. I'm out of practice with fossil. Well, it looks like Joe decided to merge trunk into the branch, so it may not be anything to worry about. I started to look at it and there were a lot of conflicts, but maybe he's more familiar with the code in question and could simply resolve the conflicts easily (or just ignored them and updated with the latest jimsh sources). Andy -- TAI64 timestamp: 400053e44dcc ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Linux 2.6 :-(
Thus said Joe Mistachkin on Thu, 07 Aug 2014 21:14:56 -0700: Yeah, it appears the net change was that Jim Tcl was updated. There are quite a lot of changes to it since the last version. However, I think it should be fine merging it to trunk? Any conflicting opinions? No, looks fine now (as far as the merge is concerned). I tried to test it by making my /home unreadable (chmod 711 /home) but then Fossil couldn't even update, and all other kinds of problems happened: $ fossil up cannot find current working directory; Permission denied $ ./configure --disable-lineedit No installed jimsh or tclsh, building local bootstrap jimsh0 Runtime Error: stdlib.tcl:87: Failed to get pwd in procedure 'info nameofexecutable' called at file ./autosetup/test-tclsh, line 11 at file stdlib.tcl, line 87 Runtime Error: stdlib.tcl:87: Failed to get pwd in procedure 'info nameofexecutable' called at file ./autosetup/test-tclsh, line 11 at file stdlib.tcl, line 87 No working C compiler found. Tried cc and gcc. $ which tclsh /usr/local/bin/tclsh $ pwd /home/src/fossil $ cd /home $ pwd /home $ ls ls: .: Permission denied $ cd src $ ls fossil So clearly it's possible to navigate, but configure doesn't like it much. I tried with --debug and didn't get any other useful info. It's also odd that it didn't think it could find tclsh (yes I forgot to make tclsh disappear, but it thought it was gone already). Andy -- TAI64 timestamp: 400053e45372 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Linux 2.6 :-(
On 8 Aug 2014, at 2:14 pm, Joe Mistachkin sql...@mistachkin.com wrote: Andy Bradford wrote: Well, it looks like Joe decided to merge trunk into the branch, so it may not be anything to worry about. Yeah, it appears the net change was that Jim Tcl was updated. There are quite a lot of changes to it since the last version. However, I think it should be fine merging it to trunk? Any conflicting opinions? Yes. Looks fine. There's no magic. All I did was check out the latest autosetup and then run: .../autosetup --install I pulled your changes, did the same thing, and it is identical. So looks good to me. -- Embedded Systems Specialists - http://workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
