Re: [fossil-users] Fossil on a Chromebook
On 8/18/2014 16:12, Ron W wrote: I have considered getting a Chrome book as a way to get a very inexpensive laptop, but this makes it sound like it would only be worth it to me if I could wipe it and install a decent Linux distro on it. I'm not aware of any small, well-built, inexpensive Linux-ready laptops other than Chromebooks. Netbooks as a class have morphed into small Windows laptops, tablets, and Chromebooks. Of those three classes, only Chromebooks remain close to the old netbook concept. Small Windows laptops usually have at least one peripheral that doesn't have a Linux driver. Tablets are often worse in that regard, plus they make poor development systems by their very keyboardless nature. The Crouton chroot system solves this problem. First, running in a chroot underneath Chrome OS solves the driver problem, since Chrome OS is only licensed to OEMs who configure it specially for the hardware they ship it on. You're running the Debian/Ubuntu userland on top of the customized Chrome OS kernel. Second, Chromebooks are intentionally mobile systems, rather than desktop replacements, which most other laptops end up being, since you really can't run OS X or Windows plus a reasonable set of desktop apps from a 16 GB flash chip, with 2 GB of RAM. Linux copes with such resource constraints nicely, the diffuse Linux phenomenon can't swing an OEM deal that brings the package to you for ~$200-250. The small number of large vendors making Chromebooks can. Running Linux this way has some advantages to counter the hassles of manually firing up the chroot. 1. You don't have to fire up the chroot at all, if you only need to do web type things. And with Chrome OS, the scope of web type things is a lot broader than with other browsers: https://chrome.google.com/webstore/category/collection/offline_enabled 2. Once booted, Chromebooks are basically instant-on after sleep, and during sleep they don't drain the battery much. When you really do have to reboot, a Chromebook will boot to a usable Chrome desktop 2-3 times faster than a traditional Linux netbook because it isn't dragging around the legacies of the BIOS and general purpose desktop computing. 3. Crouton makes it easy to encrypt your Linux chroot, while you allow your Chrome desktop system slice to remain protected only by the password. This lets you partition your world into relatively low-security things that you do on the Chrome OS side, with the sensitive stuff hidden away in the encrypted chroot box. The risks from the unencrypted Chrome OS side are small next to the risks of using a cloud-based OS in the first place. Another reason to have the encrypted Crouton chroot, if another were needed. ___ 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] crash while running 'fossil pull' on Linux
On 8/18/2014 19:39, Eric Rubin-Smith wrote: warning: Can't read pathname for load map: Input/output error. Core was generated by `/home/eric/fossil-src-20140612172556/fossil update'. Program terminated with signal 11, Segmentation fault. #0 0xb75bffb0 in ?? () from /lib/i386-linux-gnu/libcrypto.so.1.0.0 (gdb) where #0 0xb75bffb0 in ?? () from /lib/i386-linux-gnu/libcrypto.so.1.0.0 #1 0xefcdab89 in ?? () #2 0x98badcfe in ?? () #3 0x10325476 in ?? () #4 0xc3d2e1f0 in ?? () #5 0x402a84b0 in ?? () #6 0x in ?? () That looks like a corrupted stack to me. Try running it under Valgrind. It will stop the program right where the damage occurs, rather than after the damage has propagated far enough that it's trying to escape memory protection boundaries. ___ 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 on a Chromebook
On Tue, Aug 19, 2014 at 7:25 PM, Warren Young war...@etr-usa.com wrote: I'm not aware of any small, well-built, inexpensive Linux-ready laptops other than Chromebooks. Netbooks as a class have morphed into ... huge snip Thank you for those insights - i've been waivering as well, mainly because of my poor experience with setting up a dev environment on a non-Linux mobile system. 3. Crouton makes it easy to encrypt your Linux chroot, while you allow your Chrome desktop system slice to remain protected only by the password. This lets you partition your world into relatively low-security things that you do on the Chrome OS side, with the sensitive stuff hidden away in the encrypted chroot box. A colleague of mine recently reported out-of-the-box success in encrypting his root partition using the latest Mint Linux on a high-end laptop (don't remember the model - one of our newer dev laptops at work). The risks from the unencrypted Chrome OS side are small next to the risks of using a cloud-based OS in the first place. LOL! Hadn't thought about it, but having a cloud OS basically guarantees that _someone_ in the chain will eventually have access to your data, even if doing so requires a court order to the parent company (in another country). (For the record, i'm open to cloud use, but also respect concerns like the one you raise.) -- - 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] crash while running 'fossil pull' on Linux
Stephan Beal wrote: On Tue, Aug 19, 2014 at 7:31 PM, Warren Young war...@etr-usa.com wrote: On 8/18/2014 19:39, Eric Rubin-Smith wrote: warning: Can't read pathname for load map: Input/output error. That looks like a corrupted stack to me. Try running it under Valgrind. +1 I ran it under valgrind already and mentioned the results in the OP -- you probably missed that in my wall of text :-). The upshot is that valgrind's imposed slow-down causes us not to reach the bad path. So no help there. If you follow my post through to the end, though, you will see that the call to 'xfer_accept_file' in xfer.c line 1641 is strongly implicated by my gdb session. If you go and look at that function, you will see a call to blob_extract on line 139 that passes 'n', where 'n' was obtained above from the incoming data (xfer.c line 130). It seems very likely that we are placing too much trust in this 'n' during 'blob_extract'... though this is just my suspicion of course, not a certainty. and while i'm here: thank you for the tremendously detailed bug report. no problem. I've been on the receiving end of tickets like teh software doesn't work 4 me can u plz fix it enough times to try to avoid inflicting similar pain. :-) -- Eric A. Rubin-Smith ___ 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 on a Chromebook
On 8/19/2014 11:33, Stephan Beal wrote: A colleague of mine recently reported out-of-the-box success in encrypting his root partition Ubuntu's done this in its stock installer since 12.10. One of the things I trimmed from that already long post is the observation that booting through BIOS + GRUB + LUKS on a traditional laptop takes about 20 seconds, by which point you've already got a Chrome window open on a Chromebook. 20 seconds after that, the Linux laptop gets through the systemd scripts to a GUI login prompt. And 20 seconds after *that*, the system has finally stopped swapping enough that the first Iceweasel window can pop up. If you decide that Chromebooks are not for you, my previous Linux netbook ran Crunchbang Linux, a Debian 7 derivative specifically optimized for low-resource machines. Install Chrome on it, and you've got something kind of like a Chromebook, if you squint. http://crunchbang.org/ It starts up a *lot* faster than Ubuntu. Still slower than a Chromebook, though. ___ 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] crash while running 'fossil pull' on Linux
On Mon, Aug 18, 2014 at 9:39 PM, Eric Rubin-Smith eas@gmail.com wrote:
I have taken a wire capture of the cleartext client-server interaction
and can share that with the devs privately if they would like.
Please
Also, can you reproduce the problem with -O0 instead of -O2 or -Os or
whatever it is that you currently are using?
1640 if( blob_eq(xfer.aToken[0],file) ){
Knowning the content of the xfer object just before the above line runs,
might provide a clue.
(gdb)
0x08048330 in ?? ()
(gdb)
Cannot find bounds of current function
(gdb)
--
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] crash while running 'fossil pull' on Linux
On 8/19/2014 11:50, Eric Rubin-Smith wrote: Try running it under Valgrind. I ran it under valgrind already and mentioned the results in the OP -- you probably missed that in my wall of text :-). No, I just stopped reading when I saw the characteristic smashed stack gdb output. :) valgrind's imposed slow-down causes us not to reach the bad path. That suggests a race condition, which usually means a threading or TCP stream packetization problem. With Fossil, I don't believe either to be the case. What I do believe is that Valgrind's parakeets and instrumentation code move things around in memory, which can cause code that used to break to start succeeding by accident. no problem. I've been on the receiving end of tickets like teh software doesn't work 4 me can u plz fix it enough times to try to avoid inflicting similar pain. :-) What amazes me is how often you see that sort of report from other developers. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Stability of fossil test-name-to-id
Hi. I'm writing a program that depends on the functionality of test-name-to-id. Given that the command is completely undocumented and doesn't appear in any help texts, is that sufficient warning to suggest that the command may be removed at any moment and shouldn't be used for anything? I could open the repository and perform the SQL query manually, but the temptation to use a command that's already written and known to work is tempting... M ___ 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] Stability of fossil test-name-to-id
On Tue, Aug 19, 2014 at 9:12 PM, org.fossil-scm.fossil-us...@io7m.com wrote: I'm writing a program that depends on the functionality of test-name-to-id. Given that the command is completely undocumented and doesn't appear in any help texts, is that sufficient warning to suggest that the command may be removed at any moment and shouldn't be used for anything? You might be interested in a standalone alternative: [stephan@host:~/cvs/fossil/fossil]$ f-resolve trunk current prev rid:1 ee46563cbdc28face0215bc1a5cf81f0b589d88a 26866 trunk ca5d6f2b482bd08c58886b0fd4a96aaffc56f893 26901 current d8902124d481ced2a800fc3ec4d3212640c25563 26899 prev a28c83647dfa805f05f3204a7e146eb1f0d90505 1 rid:1 that's available in the libfossil sources: http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/wiki?name=f-tools I could open the repository and perform the SQL query manually, but the temptation to use a command that's already written and known to work is tempting... and has already been created as a standalone binary with documented semantics: http://fossil.wanderinghorse.net/repos/libfossil/doxygen/fossil-core_8h.html#a265d03fe1e040d7068679f9b2a4d1a11 :) -- - 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 clone over SSH
Thus said Abilio Marques on Sat, 16 Aug 2014 12:14:09 -0430: amarques@laptop-01 ~/tmp/resume $ fossil clone ssh://abiliojr@raspberry1/.fossilrepos/resume.fossil .resume.fossil abiliojr@raspberry1's password: Round-trips: 2 Artifacts sent: 0 received: 0 Error: not authorized to clone Round-trips: 2 Artifacts sent: 0 received: 0 Clone finished with 569 bytes sent, 564 bytes received server returned an error - clone aborted Just as a quick follow-up to finish out this thread. Abilio and I diagnosed this off-list and it turns out that this particular fossil had localauth=1 in the config. Having localauth=1 means that all syncs will require Fossil authorization and SSH currently cannot provide Fossil username/password except via REMOTE_USER environment variable (without the password), so he disabled it. One can certainly enable localauth=1 and have remote_user_ok=1 which would then allow the SSH client to authenticate via the REMOTE_USER environment variable, but this would require using SSH keys to force the REMOTE_USER to some value: For example, in ~/.ssh/ authorized_keys: command=env REMOTE_USER=abiliojr bin/fossil http /tmp/resume.fossil ssh-rsa ... Andy -- TAI64 timestamp: 400053f41dfc ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
