Merge lp:~emaadmanzoor/mvhub/mvhub-bzrbuilddeb-experiment into lp:mvhub

The existing criteria for accepting a merge request to trunk is:

  1) code becomes better in some way
  2) code is worse in no ways

I'm not sure if (new?) criteria should be #3 or #1a "actually does something useful" and "without too much work"

If I knew how to build a package, would these additions let me build a package ?

10 +result-dir = /var/www/mvhub/$USER/built_packages

There are other places in the code where the /var/www/mvhub/$USER nastiness exists

I'm not sure that makes it right. In the best case, we're a little hosed if $SERVER_BASE_DIR changes from /var/www/mvhub.

In the worst case this isn't going to work at all because .bzr-builddeb doesn't understand what an environment variable is and there is no literal path that contains '$USER'

From:

zless /usr/share/doc/bzr-builddeb/README.gz

> The following options are read from the configuration files. Most
> can also be used as command line arguments by prepending ``--`` to
> the names and not using the ``\=`` symbol. There are a few exceptions
> to this that are noted in the descriptions.

so creating (in perl) mv_build which calls the routines in MVHub::Wrap::ConfigSimple to get the paths see:

           perldoc MVHub::Wrap::ConfigSimple

...might be a better tactic

you will also need to modify:

    app-mvhub/project-tools/templates/template.conf

to include the built_packages dir so that:

 mv_update_development creates the directory.

> If I knew how to build a package, would these additions let me build a
> package ?
>

I forgot to add the link to the entry in the description of changes:

    * Updated the wiki with how-to-build instructions:
http://wiki.thecsl.org/mediawiki/index.php/Dev_Env_Package#To_Build_The_Package

Yes, these additions would let you build the package.

--
Emaad Ahmed Manzoor

I don't know how, but I missed your previous mails about using
MVHub::Wrap::ConfigSimple. The builddeb.conf file actually works with
environment variables (/var/www/mvhub/$USER/* works), but you're right about
being adaptable to changes in the future. Working on the mv_build_env script
now.

On Sat, Jul 9, 2011 at 11:04 AM, Dan MacNeil <email address hidden> wrote:

>
> 10 +result-dir = /var/www/mvhub/$USER/built_packages
>
> There are other places in the code where the /var/www/mvhub/$USER nastiness
> exists
>
> I'm not sure that makes it right. In the best case, we're a little hosed if
> $SERVER_BASE_DIR changes from /var/www/mvhub.
>
> In the worst case this isn't going to work at all because .bzr-builddeb
> doesn't understand what an environment variable is and there is no literal
> path that contains '$USER'
>
> From:
>
> zless /usr/share/doc/bzr-builddeb/README.gz
>
> > The following options are read from the configuration files. Most
> > can also be used as command line arguments by prepending ``--`` to
> > the names and not using the ``\=`` symbol. There are a few exceptions
> > to this that are noted in the descriptions.
>
> so creating (in perl) mv_build which calls the routines in
> MVHub::Wrap::ConfigSimple to get the paths see:
>
> perldoc MVHub::Wrap::ConfigSimple
>
> ...might be a better tactic
>
> --
>
> https://code.launchpad.net/~emaadmanzoor/mvhub/mvhub-bzrbuilddeb-experiment/+merge/66864<https://code.launchpad.net/%7Eemaadmanzoor/mvhub/mvhub-bzrbuilddeb-experiment/+merge/66864>
> You are the owner of lp:~emaadmanzoor/mvhub/mvhub-bzrbuilddeb-experiment.
>

--
Emaad Ahmed Manzoor

OPTIONAL nits (fix to suckup , but not required for merge approval)
 rename mv_build_env to mv_build

 hid status noise. / add a verbose flag
    --s there a --quiet flag

REQUIRED (or prove I'm wrong)
   chmod +x app-mvhub/project-tools/bin/mv_build_env

   run with no lintian errors

   change so build fails on lintian errors

  run if Emaad private key not available (but warn)

  run without prompting user re tar.orig

  add bzr-builddeb to build-depends

> OPTIONAL nits (fix to suckup , but not required for merge approval)
> rename mv_build_env to mv_build
>
>
You want this script to eventually build all the packages? I thought this
was only for the mvhub-dev-env package, because the mvhub/mvhub-cpan
packages might require something else. Even if they're the same, the mvhub
package will take a lot more time than the other 2, so someone testing out
the mvhub-dev-env package will have to wait unnecessarily until the mvhub
package builds too.

--
Emaad Ahmed Manzoor

app-mvhub/project-tools/bin/mv_build_env

should use

Getopt::Long;

See:

app-mvhub/bin/dump.pl
app-mvhub/bin/notification_email.pl
app-mvhub/project-tools/bin/mv_update_production
app-mvhub/project-tools/bin/mv_update_development
app-mvhub/project-tools/bin/mv_update_staging