On Thu, 18 Aug 2011 19:14:22 -0300 Gerardo Exequiel Pozzi <[email protected]> wrote:
> On 08/18/2011 06:53 AM, Dieter Plaetinck wrote: > > On Wed, 17 Aug 2011 23:38:55 -0300 > > Gerardo Exequiel Pozzi<[email protected]> wrote: > > > >> On 08/15/2011 02:14 PM, Dieter Plaetinck wrote: > >>> On Mon, 15 Aug 2011 01:43:49 -0300 > >>> Gerardo Exequiel Pozzi<[email protected]> wrote: > >>> > >>>> On 08/14/2011 08:13 AM, Dieter Plaetinck wrote: > >>>>> Hi, > >>>>> I would like to run multiple builds per day. For this I would > >>>>> like to also put the hour of building in the iso filenames. > >>>>> > >>>>> > >>>>> something like: > >>>>> > >>>>> diff --git a/configs/releng/build.sh b/configs/releng/build.sh > >>>>> index 1aa80fd..7fce685 100755 > >>>>> --- a/configs/releng/build.sh > >>>>> +++ b/configs/releng/build.sh > >>>>> @@ -4,7 +4,7 @@ set -e -u > >>>>> > >>>>> name=archlinux > >>>>> iso_label="ARCH_$(date +%Y%m)" > >>>>> -version=$(date +%Y.%m.%d) > >>>>> +version=$(date +%Y.%m.%d.%H) > >>>>> install_dir=arch > >>>>> arch=$(uname -m) > >>>>> work_dir=work > >>>>> > >>>>> > >>>>> > >>>>> Or, maybe this is too releng-specific (i.e. most people who run > >>>>> archiso probably prefer $(date +%Y.%m.%d), in which case: can > >>>>> you give archiso a flag so that I can control the version as a > >>>>> parameter? > >>>>> > >>>>> ./build.sh all_iso_single 2011.08.14.12 > >>>>> ./build.sh all_iso_dual 2011.08.14.12 > >>>>> ./build.sh all_iso_dual 2011.08.14-lets-try-some-new-code > >>>>> > >>>>> passing it as a flag would also be more robust. Things could go > >>>>> wrong (I think?) if the all_iso_single runs at 23:45 of one day > >>>>> and all_iso_dual runs at 00:15 the next morning. > >>>> Do not worry about this. You guess about LABEL? Not an issue, > >>>> LABEL for dual is also generated at build time (not read from > >>>> "single" work). Also you can have a 201112 and 201201. :P > >>> That's the point. If I build multiple isos after each other (like > >>> first single isos, then duals) I want all of them to have the same > >>> version. > >>> > >>>> what do you think about via env var? > >>> It's possible but I don't like it. If we already have option > >>> passing through cmdline args, I think we should pass new options > >>> that way too. Also it makes it very clear to the user what you can > >>> do (implenting ./build.sh -h which would show all flags with > >>> explanation) while you're at it, probably a good idea to use > >>> getopt and make verbosity also controllable with a flag. (now my > >>> code needs to call sed on your script..) > >>> > >>> Dieter > >>> > >> How about this? > >> > >> usage ./build.sh [options] command<command options> > >> > >> General options: > >> -N<iso_name> Set an iso filename (prefix) > >> Default: archlinux > >> -V<iso_version> Set an iso version (in filename) > >> Default: 2011.08.17 > >> -L<iso_label> Set an iso label (disk label) > >> Default: ARCH_201108 > >> -D<install_dir> Set an install_dir (directory inside iso) > >> Default: arch > >> -w<work_dir> Set the working directory > >> Default: work > >> -o<out_dir> Set the output directory > >> Default out > >> -v Enable verbose output > >> -h This help message > >> > >> Commands: > >> build<mode> <type> > >> Build selected .iso by<mode> and<type> > >> purge<mode> > >> Clean working directory except iso/ directory of > >> build<mode> clean<mode> > >> Clean working directory and .iso file in output directory > >> of build<mode> > >> > >> Command options: > >> <mode> Valid values 'single' or 'dual' > >> <type> Valid values 'net', 'core' or 'all' > >> > >> > > looks perfect > > > > Do you want this merged before next official snapshot? > > Take care that this break current releng script, should be adapted to > newer commands. > > ./build.sh all_iso_single -> ./build.sh build single all > ./build.sh all_iso_dual -> ./build.sh build dual all > ./build.sh clear_dual -> ./build.sh clear dual > ./build.sh purge_single -> ./build.sh purge single > etc... > > Also iso images are now placed in "out" by default (without -o) > instead of ".", doing this more organized. > > You may want to use newer -L and -V ;) > > if you're sure it works okay, then yes you can push it. otherwise i'ld rather stick with what works. Dieter
