Bootstrapped snapshots

Mon Mar 25 16:06:57 UTC 2013

On Sun, Mar 24, 2013 at 5:46 PM, Rempel, Cynthia
<cynt6007 at vandals.uidaho.edu> wrote:
> Hi Dr. Sherrill,
>
> Perhaps two snapshots: yesterday, and the day before, as a user who REALLY wants an old snapshot could probably reconstruct one from an old git commit number? These aren't releases, after all.
>
That might be reasonable.

> Could it just be the core of rtems, like
>
> git clone git://git.rtems.org/rtems.git
> cd rtems
> ./bootstrap
> cd ..
> tar -acf tar -acf rtems-snapshot-YYYYMMDD.tar.xz rtems
>
> (lzma might be yield a smaller file, but I don't know how to do that)
>
It might be easier to just name it rtems-git-nightly.tar.xz and
overwrite it each day. Or two days at a time.

> Could we not tag the snapshots in git, but rather make sure the git information needed for someone to run git diff from them?
>
Don't need to pollute our repo with daily tags. It would be better to
put the commit name (the SHA1) somewhere in the snapshot. It might
also be a good idea to include some log or automated changelog file.
This could perhaps refer to some other tag, and only include the most
recent changes. It could also be given as a separate file for
download, e.g. rtems-log-nightly.xz

> Would it be possible to set it up so someone could get other people's changes from the snapshot, maybe like running git pull? Maybe even having the snapshot check if it's more than a week old, refusing to run git pull and telling the user to get a new snapshot.
>
I don't think that would work without providing a git clone as the snapshot.

> Would it be desirable/feasible to throttle how quickly the snapshot gets downloaded?
>
> Could we make it difficult/pointless to run rsync on this file?
>
> Would it help to put them on the http://www.rtems.org/ftp/pub/rtems/SOURCES/4.11/
>
> Thanks,
> Cynthia Rempel
> ________________________________________
> From: Joel Sherrill [joel.sherrill at oarcorp.com]
> Sent: Sunday, March 24, 2013 11:29 AM
> To: Rempel, Cynthia
> Cc: Ralf Corsepius; rtems-devel at rtems.org
> Subject: Re: Building and Testing a Canadian Cross-Compiler
>
> On 3/24/2013 1:06 PM, Rempel, Cynthia wrote:
>> Hi Ralf Corsepius,
>>
>> We could propose a compromise of daily (or weekly) snapshots of the git repository, pre-bootstrapped...
> I actually have a script that did this for the CVS tree.
>
> I did it to support Jennifer while was at a customer site
> with nothing but http Internet access.
>> Could you determine if it's feasible to do a daily (or weekly) snapshot of a pre-bootstrapped git repository, and how to set-up git to ignore the autogenerated files when generating a .diff?
> That is easy. It is a .gitignore file. There is one at the top of the
> tree that
> already does this:
>
> $ cat .gitignore
> aclocal.m4
> autom4te.cache
> configure
> config.h.in
> Makefile.in
>
>> If the pre-bootstrapped snapshot method is feasible, acceptable, and you wanted to commit from the snapshot, you could then run configure without bootstrap...
>  From my perspective, the biggest issue would be policy on cutting and
> retention.
>
> How long do we keep them on the disk?
>    - The issue is a combination of disk space and and people mirroring
> the snapshots.
>      This sucks the bandwidth badly. Periodically some *&^R% does an
> rsync mirror from
>      the top when they really only want a file or two.  This is a
> problem as the site grows.
>      It is now about 500GB.
> Do they get tagged in git when cut?
> What are they named?
> Is it a full clone? tar cJf results in a 68 MB tar file.
>
> It is trivial technically but I would recommend we only keep a few.
>> Thanks,
>> Cynthia Rempel
>> ________________________________________
>> From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Ralf Corsepius [ralf.corsepius at rtems.org]
>> Sent: Sunday, March 24, 2013 9:41 AM
>> To: rtems-devel at rtems.org
>> Subject: Re: Building and Testing a Canadian Cross-Compiler
>>
>> On 03/23/2013 07:12 PM, Rempel, Cynthia wrote:
>>> Thanks Sebastian Huber for finding that tutorial for a building a Canadian cross-compiler.
>>> http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler
>>>
>>> I found a rather out-dated tutorial for testing Canadian cross-compilers
>>> http://kegel.com/crosstool/current/doc/crosstest-howto.html
>>>
>>> It's possible that there might be additional testing resources in
>>> http://git.rtems.org/rtems-testing
>>>
>>> I found gcc/do_one rather interesting...
>>>
>>> I am curious now, if neither minGW nor Cygwin are needed for RTEMS except for the auto-tools, would it be feasible to automatically generate daily (or weekly) snap-shots that are already boot-strapped?
>> Yes, definitely ... The autotool generated sources (e.g. Makefile.in,
>> config.h etc.) definitely belong into git.
>>
>> However, when having done so, the patches were immediately reverted and
>> was virtually shot down - These incidents actually are the reason for my
>> current deep dissatisfation with certain people around here.
>>
>>> And if so, what else would be required to get the RTEMS tool-set working for Windows users without Cygwin or minGW?
>> This would be very hard if not impossible. You basically need a
>> POSIX-shell environment and a POSIX compliant native C-compiler.
>>
>> Providing these essentially are the core of MingGW and Cygwin.
>>
>> Ralf
>>
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>>
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>
>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel