Re: [Gnewsense-dev] Current Status (and Wiki Performance)

[Sam Geeraerts]

Op Fri, 23 Dec 2016 23:26:48 -0500
schreef dww <address@hidden>:

> Is the procedure creating a local repository of upstream source code
> and build artifacts and gNewSense modified source code and build
> artifacts starting with those from an upstream mirror defined in
> MIRROR?

It creates a local full (source + binaries) repository of upstream in
MIRROR. The gNewSense repo is initially a copy of that. As you add gen
scripts, you get gNewSense specific packages in the gNewSense repo.

> Would you please explain what the different mirrors are (MIRRORLOCAL
> and MIRROR)?  In the text in Step 3 for MIRROR it refers to step 5,
> but step 5 is about installing certain packages needed to run Builder
> properly.

MIRRORLOCAL is the path to the upstream mirror on your hard drive.
MIRROR is the same repo, but then as an HTTP path. Step 3 should refer
to step 4. Fixed now.

> In step 4 I think debmirror is used to create a local mirror at
> location in MIRRORLOCAL?  Is this the mirror to which the build from
> the repository generated and updated in steps 6 and 7 is pushed in
> step 9.

MIRRORLOCAL remains unchanged, because that's upstream. The result of
the update goes in REPODST.

> Or is MIRRORLOCAL the mirror that should be a location on a
> distribution server?

What do you mean by "distribution server"?

> Does ./do-update actually build binaries from code in the repository
> or I should ask specifically what do debmirror and do-update
> accomplish?

Debmirror syncs with upstream, do-update checks if a package needs
updating and runs the gen script if it does.

> (Note)In step 7 should the pushing of changes be done in step 9 not
> 7?)

Indeed. Fixed now.

> I would appreciate any description of what the different steps do
> rather than just how?

1. Generate a key to sign your gNewSense repo.
2. Get the Builder source code so that you can run it.
3. Configure Builder for your needs.
4. Get the upstream repo.
5. Install Builder's runtime dependencies.
6. Set up your gNewSense repo, i.e. write reprepro's configuration.
7. Fill your gNewSense repo and modify packages that require it.
8. Generate a live CD. You run this only with a new release.
9. Make your repo public (all the previous steps happened in folders
that the outside world doesn't see).

>  Could I run Builder from an external hard drive such as a Western
> Digital WD Elements which would guarantee sufficient disk space?

Sure. It might be a bit slower, but technically there's no problem.

> I noticed that the in the config file for Builder from the gNewSense
> Savannah repository that BASEDIR and MIRRORLOCAL are in srv in the
> file system. Can this be on an external drive instead?

It can be anywhere you like.

> So basically, patching packages involves creating gen script files
> with basically sed scripts for applying changes to package source
> files?

A gen script does the following:

1. Unpack the source package.
2. Modify the source code.
3. Repack the source package.
4. Build the binary packages.

It's the same as what you do when you modify a package by hand. The
second step does what you would do with an editor. Sed is a convenient
way to change text, but you could also use another method. You could
also create patches like we do for Ucclia and put the commands to do
that in the gen script. E.g.:

cat <<HERE >/tmp/my_patch
--- a/foo/bar
+++ b/foo/bar
@@ -1,2 +1,2 @@
-This is old.
+This is new.
 The end.
HERE
quilt import /tmp/my_patch

The advantage of sed is that you don't have to change the scripts if
line numbers change.

> What is the procedure for building and testing the modified packages,
> that is, how are the gen scripts run by themselves along with the
> config file? Is it just run as a bash script?

It's just a bash script that you can run without running all of Builder.