Bootstrapped snapshots

Wed Mar 27 03:14:16 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.
That sounds good.

>> 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.
>>
> don't think that would work without providing a git clone as the snapshot.
Would it suffice to write a helper script to replace all 1.12.6 with 1.11.1, and 2.69 with 2.62? Then also add the configure.ac s to the .gitignore? Once this change is made, is there still a problem?  Would a simple diff between the git before the bootstrap and after the bootstrap meet the need?

> 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