Re: [fossil-users] Linux binary downloads

2017-02-20 Thread Emil Totev 
> Subject: Re: [fossil-users] Linux binary downloads
> On 2/20/17, Emil Totev  wrote:
>> Hi
>>
>> There are still inconsistencies in the binary downloads for linux at
>> fossil's web site.
>>
>> File fossil-linux-x86-1.37.tar.gz contains a x64 (64-bit) executable.
>> There seems to be no 32-bit linux executable download.
>>
>> Could someone please fix that for this and future builds?
>
> I suspect that the Mac and OpenBSD builds are 64-bits too.  I suppose
> we could produce 32-bit binaries, but I worry that they would be
> largely untested, since I use 64-bit machines almost exclusively, as I
> suspect most of the other Fossil developers do as well.  If you really
> need a 32-bit binary, you can always build your own use the source
> tarball, right?
>
> Or, perhaps you are simply asking that the downloads be relabeled from
> "x86" to "x64"?
>

Well, at least relabeling the downloads (and renaming the files
itself) in order to avoid confusion would be nice.

I guess I could build my own binary, of course, but I've always felt
more comfortable using 'official' binaries. And 32-bit Linux is far
from being an exotic platform even these days.

Thanks
Emil
___
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] Longest gap between check-ins

2017-02-20 Thread Andy Bradford 
Thus said Richard Hipp on Mon, 20 Feb 2017 10:39:09 -0500:

> Now remind me again, how would you do this in Git? ;-)

To get these kinds of reports  I import my Git repositories into Fossil.
:-)

Andy
-- 
TAI64 timestamp: 400058ab1b40


___
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 binary downloads

2017-02-20 Thread Andy Bradford 
Thus said Richard Hipp on Mon, 20 Feb 2017 07:40:43 -0500:

> I suspect that  the Mac and OpenBSD builds are  64-bits too. I suppose
> we  could produce  32-bit binaries,  but I  worry that  they would  be
> largely untested, since I use 64-bit machines almost exclusively, as I
> suspect most of the other Fossil developers do as well.

I run Fossil  both on 32-bit and 64-bit OpenBSD,  with 32-bit being more
heavily used at present.

Andy
-- 
TAI64 timestamp: 400058ab1ac4


___
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 binary downloads

2017-02-20 Thread sky5walk 
Ah, I see it is somewhat quirky:
https://wiki.openssl.org/index.php/Compilation_and_Installation#W64

Thanks for explaining the Windows x64 gap.

On Mon, Feb 20, 2017 at 10:42 AM, Richard Hipp  wrote:

> On 2/20/17, sky5w...@gmail.com  wrote:
> > Any chance to get the Windows binary as x64 also?
>
> The problem with that (for me at least) is that it is difficult to
> compile the OpenSSL library using MSVC.  OpenSSL really wants to be
> compiled with MinGW.  And I only have a 32-bit MingGW compiler.  So
> (for me at least) the choices are 32-bit Windows builds, or 64-bit
> builds that lack "https" capabilities.
>
> --
> 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
>
___
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] Longest gap between check-ins

2017-02-20 Thread Javier Guerra Giraldez 
On 20 February 2017 at 15:39, Richard Hipp  wrote:
> I don't know if the above has any practical use for most people (or I
> would make it a new URI on the Fossil webserver) but it seems like fun
> and so I thought I would share.


sure!, it serves to document sleep patterns without having to strap an
IoT (aka DDOS source) device! :-)

-- 
Javier
___
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] fast-import crash (mark not declared)

2017-02-20 Thread Petr Ovtchenkov 
On Fri, 17 Feb 2017 00:19:08 -0600
Artur Shepilko  wrote:

> To summarize the findings:
>  - Sqlite Fossil repo has a number of special cases that do not export
> directly, resulting in "git fast-import" crash.
>  - To accomplish the export, one needs to apply the following fixes to
> the __local__ clone of the Sqlite Fossil repo:
> fossil set autosync off
> fossil reparent 590d4ac1ee0db824 eb7a544fe49d1626bacecfe53ddc03fe082e3243
> fossil amend 655991ec8a --date "2010-09-28 19:16:47"
> fossil amend 1ef0dc9328 --date "2010-09-29 13:31:00"
> 
> Then initiate the fossil export process anew.
> Please take a note of NOT pushing any of these changes into the Sqlite
> remote repo.

Conformed:

fossil set autosync off
fossil reparent 590d4ac1ee0db824 eb7a544fe49d1626bacecfe53ddc03fe082e3243
fossil amend 655991ec8a --date "2010-09-28 19:16:47"
fossil amend 1ef0dc9328 --date "2010-09-29 13:31:00"
cd ../sqlite-git && fossil export --git \
  --export-marks ../sqlite-fossil/fossil.marks ../sqlite.fossil | \
  git fast-import --import-marks=../sqlite-fossil/git.marks 
--export-marks=../sqlite-fossil/git.marks

Give

error: multiple updates for ref 'refs/tags/experimental' not allowed.
git-fast-import statistics:
-
Alloc'd objects: 115000
Total objects:39137 ( 74446 duplicates  )
  blobs  :0 ( 49034 duplicates  0 deltas of 
 0 attempts)
  trees  :27819 ( 18184 duplicates  25217 deltas of  
25356 attempts)
  commits:11125 (  7228 duplicates  0 deltas of 
 0 attempts)
  tags   :  193 ( 0 duplicates  0 deltas of 
 0 attempts)
Total branches: 656 (  1220 loads )
  marks:1048576 ( 67387 unique)
  atoms:   1879
Memory total:  7876 KiB
   pools:  2485 KiB
 objects:  5390 KiB
-
pack_report: getpagesize()=   4096
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit  = 8589934592
pack_report: pack_used_ctr=  64171
pack_report: pack_mmap_calls  =   1817
pack_report: pack_open_windows=  2 /  2
pack_report: pack_mapped  =  923989449 /  923989449
-

i.e. success.

Don't forget to run

  git gc --aggressive --prune=all

Before:

  du -hs .
  884M  .

After:

  du -hs .
  33M   .


Thanks!

--


   - ptr
  
___
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 binary downloads

2017-02-20 Thread Richard Hipp 
On 2/20/17, sky5w...@gmail.com  wrote:
> Any chance to get the Windows binary as x64 also?

The problem with that (for me at least) is that it is difficult to
compile the OpenSSL library using MSVC.  OpenSSL really wants to be
compiled with MinGW.  And I only have a 32-bit MingGW compiler.  So
(for me at least) the choices are 32-bit Windows builds, or 64-bit
builds that lack "https" capabilities.

-- 
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

[fossil-users] Longest gap between check-ins

2017-02-20 Thread Richard Hipp 
For a report, I wanted to know the longest interval between to
check-ins (not necessarily on the same branch) for a project.  In
other words, I wanted to know the longest period of inactivity for a
project.  Turns out this is relatively easy to do with Fossil and some
SQL.  This message is just to record my technique.

Here's what you do:

(1) Start up the SQL shell on the repository of interest:  "fossil sql".

(2) Enter the following query:

SELECT
  (SELECT min(mtime) FROM event AS x
WHERE type='ci' AND x.mtime>y.mtime) - y.mtime,
  datetime(y.mtime),
  (SELECT substr(uuid,1,10) FROM blob WHERE blob.rid=y.objid)
FROM event AS y
WHERE y.type='ci'
ORDER BY 1 DESC LIMIT 20;

The result table shows three columns which are the length of the
check-in hiatus, the start of the hiatus, and the last check-in before
the start of the hiatus.  The 20 longest gaps are shown.

If you want to find the longest period of inactivity during 2016, you
can change the query to something like this:

SELECT
  (SELECT min(mtime) FROM event AS x
WHERE type='ci' AND x.mtime>y.mtime) - y.mtime,
  datetime(y.mtime),
  (SELECT substr(uuid,1,10) FROM blob WHERE blob.rid=y.objid)
FROM event AS y
WHERE y.type='ci'
  AND y.mtime BETWEEN julianday('2016-01-01') AND julianday('2017-01-01')
ORDER BY 1 DESC LIMIT 20;

The extra term on the outer WHERE clause limits attention to 2016.
For SQLite, the first few lines of result are this:

5.20565651590005,'2016-07-16 11:47:45','613c1ceaf4'
4.05957302125171,'2016-10-27 14:51:02','6374978e8f'
3.09464070573449,'2016-08-13 14:30:23','c7a9f26d11'
3.08603967586532,'2016-12-18 17:42:00','165c044686'
3.04145763907582,'2016-12-02 19:07:03','6e144735ed'
2.91312336781994,'2016-06-17 19:27:13','998095aba0'
2.8035011109896,'2016-08-29 14:18:18','6602974d17'

On the Tcl repository, looking over the entire lifetime of the
repository, we see:

33.903420810122,'2011-01-25 22:33:56',46969
33.1645138878375,'1998-03-26 14:56:55',886
20.9625462959521,'2000-12-14 22:24:45',9088
18.4955671289936,'1999-09-02 16:26:51',6397
16.7785532400012,'1998-04-29 17:10:32',1421
16.1128009259701,'1999-12-22 23:48:56',6930

Here we see some a few long gaps back in the 20th century, but at the
top of the list is the great sourceforge outage of 2011.

I don't know if the above has any practical use for most people (or I
would make it a new URI on the Fossil webserver) but it seems like fun
and so I thought I would share.

Now remind me again, how would you do this in Git?  ;-)

-- 
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] Linux binary downloads

2017-02-20 Thread sky5walk 
Any chance to get the Windows binary as x64 also?

Thanks for Fossil.

On Mon, Feb 20, 2017 at 9:58 AM, Roy Keene  wrote:

> I'd vote for x86_64 or amd64 (or even EM64T), but not "x64" (which is
> gibberish).
>
> On Mon, 20 Feb 2017, Richard Hipp wrote:
>
> On 2/20/17, Emil Totev  wrote:
>>
>>> Hi
>>>
>>> There are still inconsistencies in the binary downloads for linux at
>>> fossil's web site.
>>>
>>> File fossil-linux-x86-1.37.tar.gz contains a x64 (64-bit) executable.
>>> There seems to be no 32-bit linux executable download.
>>>
>>> Could someone please fix that for this and future builds?
>>>
>>
>> I suspect that the Mac and OpenBSD builds are 64-bits too.  I suppose
>> we could produce 32-bit binaries, but I worry that they would be
>> largely untested, since I use 64-bit machines almost exclusively, as I
>> suspect most of the other Fossil developers do as well.  If you really
>> need a 32-bit binary, you can always build your own use the source
>> tarball, right?
>>
>> Or, perhaps you are simply asking that the downloads be relabeled from
>> "x86" to "x64"?
>>
>> --
>> 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
>>
>> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
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 binary downloads

2017-02-20 Thread Roy Keene 
I'd vote for x86_64 or amd64 (or even EM64T), but not "x64" (which is 
gibberish).


On Mon, 20 Feb 2017, Richard Hipp wrote:


On 2/20/17, Emil Totev  wrote:

Hi

There are still inconsistencies in the binary downloads for linux at
fossil's web site.

File fossil-linux-x86-1.37.tar.gz contains a x64 (64-bit) executable.
There seems to be no 32-bit linux executable download.

Could someone please fix that for this and future builds?


I suspect that the Mac and OpenBSD builds are 64-bits too.  I suppose
we could produce 32-bit binaries, but I worry that they would be
largely untested, since I use 64-bit machines almost exclusively, as I
suspect most of the other Fossil developers do as well.  If you really
need a 32-bit binary, you can always build your own use the source
tarball, right?

Or, perhaps you are simply asking that the downloads be relabeled from
"x86" to "x64"?

--
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


___
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 binary downloads

2017-02-20 Thread Richard Hipp 
On 2/20/17, Emil Totev  wrote:
> Hi
>
> There are still inconsistencies in the binary downloads for linux at
> fossil's web site.
>
> File fossil-linux-x86-1.37.tar.gz contains a x64 (64-bit) executable.
> There seems to be no 32-bit linux executable download.
>
> Could someone please fix that for this and future builds?

I suspect that the Mac and OpenBSD builds are 64-bits too.  I suppose
we could produce 32-bit binaries, but I worry that they would be
largely untested, since I use 64-bit machines almost exclusively, as I
suspect most of the other Fossil developers do as well.  If you really
need a 32-bit binary, you can always build your own use the source
tarball, right?

Or, perhaps you are simply asking that the downloads be relabeled from
"x86" to "x64"?

-- 
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

[fossil-users] Linux binary downloads

2017-02-20 Thread Emil Totev 
Hi

There are still inconsistencies in the binary downloads for linux at
fossil's web site.

File fossil-linux-x86-1.37.tar.gz contains a x64 (64-bit) executable.
There seems to be no 32-bit linux executable download.

Could someone please fix that for this and future builds?


Regards
Emil
___
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-users Digest, Vol 109, Issue 26

2017-02-20 Thread Aldo Nicolas Bruno 
On 19/02/2017 21:27, Ron W wrote:
>  
> Currently there is no one in the Fossil community to run such a "chat
> room".

I know the existence of  a ##fossil channel on freenode.net but maybe
it's not official... :)

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users