openbsdbinpatch-misc — General discussion about OpenBSD's binpatch

Re: [Openbsdbinpatch-misc] Patch for /var/db/binpatch stuff

[Mike E. <mi...@er...>]

Gerardo Santana G=F3mez Garrido wrote:
> 2007/1/11, Mike Erdely <mi...@er...>:
>> Here's a patch that creates /var/db/binpatch, creates a file for the=20
>> patch being
>> created and copies the PLIST into it and copies that file to=20
>> /var/db/binpatch in
>> the actual binpatch tarball.
>=20
> But, isn't it a job for patch_add?

There currently isn't a(n) (official) patch_add.

> If we make a difference between a build server (binpatch framework)
> and patch tools (patch_*) I think the later should handle
> /var/db/binpatch.

Unless you want to keep it simple and have the binpatch "tools" be option=
al.  If=20
you have all of the components in the tarball, it doesn't matter whether =
you use=20
patch_add or tar, the result should be the same.

-ME

Re: [Openbsdbinpatch-misc] hello list

[<ger...@gm...>]

2007/1/11, Mike Erdely <mi...@er...>:
> Gerardo Santana G=F3mez Garrido wrote:
> > Indeed. I like them. I have read them many times and haven't found
> > anything I'd like to change so far.
> >
> > They can be enriched though if someone else has another idea/script.
> >
> > Otherwise, I'd like to have your permission z0mbix to add them to the
> > binpatch distribution.
>
> What might be a good idea is creating two ports or a binpatch port with a
> binpatch-build multi-package.  The binpatch port installed scripts like z=
0mbix's
> with a /usr/local/share/examples/binpatch/binpatch.conf (@sample'd to
> /etc/binpatch.conf) with a mirror list (which I, for instance, would modi=
fy to
> point to my local mirror of binpatches or it could point to, like,
> http://erdelynet.com/downloads/4.0/).

Aha, and/or BINPATCH_PATH, similar to PKG_PATH.

>
> Then, most users could install the "binpatch" package to install binpatch=
es made
> and stored on a local mirror.  The build box could have the binpatch-buil=
d and
> binpatch packages installed to build binpatches.
>
> Just thinking out loud.

Sounds good.

--=20
Gerardo Santana

Re: [Openbsdbinpatch-misc] Patch for /var/db/binpatch stuff

[<ger...@gm...>]

2007/1/11, Mike Erdely <mi...@er...>:
> Here's a patch that creates /var/db/binpatch, creates a file for the patch being
> created and copies the PLIST into it and copies that file to /var/db/binpatch in
> the actual binpatch tarball.


But, isn't it a job for patch_add?

If we make a difference between a build server (binpatch framework)
and patch tools (patch_*) I think the later should handle
/var/db/binpatch.


-- 
Gerardo Santana

[Openbsdbinpatch-misc] Patch for /var/db/binpatch stuff

[Mike E. <mi...@er...>]

Here's a patch that creates /var/db/binpatch, creates a file for the patch being 
created and copies the PLIST into it and copies that file to /var/db/binpatch in 
the actual binpatch tarball.

-ME

Re: [Openbsdbinpatch-misc] hello list

[Mike E. <mi...@er...>]

Gerardo Santana G=F3mez Garrido wrote:
> Indeed. I like them. I have read them many times and haven't found
> anything I'd like to change so far.
>=20
> They can be enriched though if someone else has another idea/script.
>=20
> Otherwise, I'd like to have your permission z0mbix to add them to the
> binpatch distribution.

What might be a good idea is creating two ports or a binpatch port with a=
=20
binpatch-build multi-package.  The binpatch port installed scripts like z=
0mbix's=20
with a /usr/local/share/examples/binpatch/binpatch.conf (@sample'd to=20
/etc/binpatch.conf) with a mirror list (which I, for instance, would modi=
fy to=20
point to my local mirror of binpatches or it could point to, like,=20
http://erdelynet.com/downloads/4.0/).

Then, most users could install the "binpatch" package to install binpatch=
es made=20
and stored on a local mirror.  The build box could have the binpatch-buil=
d and=20
binpatch packages installed to build binpatches.

Just thinking out loud.

Also, I made patches for binpatch (which I will send in a couple minutes)=
 that=20
creates a package list and stores it in /var/db/binpatch at the patch cre=
ation=20
point (stored in the tarball).  z0mbix's scripts could be modified to use=
 that=20
information.

-ME

Re: [Openbsdbinpatch-misc] hello list

[z0mbix <zo...@zo...>]

yes ofcourse, go for it. There's probably alot more that can be added,
but I don't really see the point, there's some simple error checking.
Maybe something a little more intelligent when it comes to replacing
kernels.

Cheers z0mbix

On 11/01/07, Gerardo Santana G=F3mez Garrido <ger...@gm...> wr=
ote:
> 2007/1/11, Antoine Jacoutot <aja...@lp...>:
> > On Thu, 11 Jan 2007, z0mbix wrote:
> > > Sorry, try now. dyndns not working for some reason.
> >
> > They look simple, which is good.
> > AFAIK, I think this is an exemple of what should be after.
>
> Indeed. I like them. I have read them many times and haven't found
> anything I'd like to change so far.
>
> They can be enriched though if someone else has another idea/script.
>
> Otherwise, I'd like to have your permission z0mbix to add them to the
> binpatch distribution.
>
> --
> Gerardo
>

Re: [Openbsdbinpatch-misc] hello list

[<ger...@gm...>]

2007/1/11, Antoine Jacoutot <aja...@lp...>:
> On Thu, 11 Jan 2007, z0mbix wrote:
> > Sorry, try now. dyndns not working for some reason.
>
> They look simple, which is good.
> AFAIK, I think this is an exemple of what should be after.

Indeed. I like them. I have read them many times and haven't found
anything I'd like to change so far.

They can be enriched though if someone else has another idea/script.

Otherwise, I'd like to have your permission z0mbix to add them to the
binpatch distribution.

-- 
Gerardo

Re: [Openbsdbinpatch-misc] hello list

[Antoine J. <aja...@lp...>]

On Thu, 11 Jan 2007, z0mbix wrote:
> Sorry, try now. dyndns not working for some reason.

They look simple, which is good.
AFAIK, I think this is an exemple of what should be after.

-- 
Antoine

Re: [Openbsdbinpatch-misc] hello list

[z0mbix <zo...@zo...>]

Sorry, try now. dyndns not working for some reason.

On 11/01/07, Antoine Jacoutot <aja...@lp...> wrote:
> On Wed, 10 Jan 2007, z0mbix wrote:
> > http://www.zombix.org/code/patch_add
> > http://www.zombix.org/code/patch_info
>
> Error 404
>
> --
> Antoine
>

Re: [Openbsdbinpatch-misc] hello list

[Antoine J. <aja...@lp...>]

On Wed, 10 Jan 2007, z0mbix wrote:
> http://www.zombix.org/code/patch_add
> http://www.zombix.org/code/patch_info

Error 404

-- 
Antoine

Re: [Openbsdbinpatch-misc] hello list

[z0mbix <zo...@zo...>]

On 10/01/07, Ingo Schwarze <sch...@us...> wrote:
> Hi Gerardo, salut Antoine,
>
> Gerardo Santana G=F3mez Garrido wrote on Wed, Jan 10, 2007:
> > 2007/1/9, Antoine Jacoutot <aja...@lp...>:
>
> >> - no need to install the sets, use mtree (drawback, make the
> >>   patches bigger), so anyone with a stable system and /usr/src
> >>   can create binpatches
> >
> > I'm not sure about this.  I'd like to hear opinions of the other
> > members of the list.
>
> Usually, i hate options (in particular useless and complicated ones).
> In this case, an option might make sense, though.
>
> Both types of patches have their relevant advantage:
> Using mtree doesn't require getting and unpacking install sets.
> Using the install sets minimizes patch size.
>
> Besides, the effect of this option will be strictly local
> at a single point inside the bsd.binpatch.mk file, so the
> resulting obfuscation will be minimal.
>
> I suggest to keep the variant using the install sets as the
> default.  Usually, you do have the install sets (otherwise, how
> did you install the OS in the first place?), and usually, the
> machine used for building binpatches will not be short on
> resources (rather, the machine the binpatches are built for
> might be a small or slow one).
>
> > As much as I agree that it would be a convenience to get a way
> > to use mtree and so avoid installing the sets (it would be faster
> > and require less disk space), I think binpatch would not make
> > sense anymore if we pack files others than the modified ones.
> >
> > Or am I missing something?
>
> Building an mtree-style binpatch is even simpler than building
> a standard binpatch.  Installing an mtree-style binpatch requires
> only a little more resources than installing a standard binpatch -
> yet, compared to the standard solution make release(8), it is
> still *much* less demanding.  Thus, no, i do not think Antoine's
> suggestion would render binpatch useless.
>
> On the other hand, it would be a pity if the possibility to
> minimize patch size were given up completely.
>
> [...]
> > I'd like to keep binpatch's approach as simple as possible.
>
> I do strongly agree.
>
> Yours,
>   Ingo
>

I'm happy with the way binpatch is, nice and simple. As previously
stated above, most people have the install sets to hand on the build
server anyway so I see no need to change things. I have been using
binpatch for a couple of years now with great success. Here are my
patch_add and patch_info that I use to manage my binpatches:

http://www.zombix.org/code/patch_add
http://www.zombix.org/code/patch_info

Cheers z0mbix

Re: [Openbsdbinpatch-misc] hello list

[Ingo S. <sch...@us...>]

Hi Gerardo, salut Antoine,

Gerardo Santana Gómez Garrido wrote on Wed, Jan 10, 2007:
> 2007/1/9, Antoine Jacoutot <aja...@lp...>:

>> - no need to install the sets, use mtree (drawback, make the
>>   patches bigger), so anyone with a stable system and /usr/src
>>   can create binpatches
> 
> I'm not sure about this.  I'd like to hear opinions of the other
> members of the list.

Usually, i hate options (in particular useless and complicated ones).
In this case, an option might make sense, though.

Both types of patches have their relevant advantage:
Using mtree doesn't require getting and unpacking install sets.
Using the install sets minimizes patch size.

Besides, the effect of this option will be strictly local
at a single point inside the bsd.binpatch.mk file, so the
resulting obfuscation will be minimal.

I suggest to keep the variant using the install sets as the
default.  Usually, you do have the install sets (otherwise, how
did you install the OS in the first place?), and usually, the
machine used for building binpatches will not be short on
resources (rather, the machine the binpatches are built for
might be a small or slow one).

> As much as I agree that it would be a convenience to get a way
> to use mtree and so avoid installing the sets (it would be faster
> and require less disk space), I think binpatch would not make
> sense anymore if we pack files others than the modified ones.
> 
> Or am I missing something?

Building an mtree-style binpatch is even simpler than building
a standard binpatch.  Installing an mtree-style binpatch requires
only a little more resources than installing a standard binpatch -
yet, compared to the standard solution make release(8), it is
still *much* less demanding.  Thus, no, i do not think Antoine's
suggestion would render binpatch useless.

On the other hand, it would be a pity if the possibility to
minimize patch size were given up completely.

[...]
> I'd like to keep binpatch's approach as simple as possible.

I do strongly agree.

Yours,
  Ingo

Re: [Openbsdbinpatch-misc] hello list

[Antoine J. <aja...@lp...>]

On Wed, 10 Jan 2007, Gerardo Santana G=F3mez Garrido wrote:
> As much as I agree that it would be a convenience to get a way to use
> mtree and so avoid installing the sets (it would be faster and require
> less disk space), I think binpatch would not make sense anymore if we
> pack files others than the modified ones.

Well it would still make sense as even if there're a bit bigger than the=20
ones actually built that wouldn't change anything about binpatches=20
greatness ;-)

I just find it more convenient not to have to unpack all sets... but well=
,=20
that's just me!

> I would be glad to add it. I'd like some enlightenment here too,
> please. I remember that some people (like me) is unable to see why a
> patch would be uninstalled. If the patch was incorrect, patch again.

Totally agree.

> I'd like to keep binpatch's approach as simple as possible. I like to
> think of a binary patch as a simple tarball to unpack on / as opposed
> to Solaris's patch dependencies and special programs to handle it.

I think a small patch_add and patch_info (or patch_list or whatever) woul=
d=20
be nice and easy to do.
patch_delete is not needed indeed.

--=20
Antoine

Re: [Openbsdbinpatch-misc] hello list

[<ger...@gm...>]

2007/1/9, Antoine Jacoutot <aja...@lp...>:
> Hey.
>
> Glad to see binpatch under the light again.

Hey Antoine :-)  thanks for coming.

>
> To follow the todo thread, interesting features could be:
>
> - no need to install the sets, use mtree (drawback, make the patches
> bigger), so anyone with a stable system and /usr/src can create binpatches

I'm not sure about this. I'd like to hear opinions of the other
members of the list.

As much as I agree that it would be a convenience to get a way to use
mtree and so avoid installing the sets (it would be faster and require
less disk space), I think binpatch would not make sense anymore if we
pack files others than the modified ones.

Or am I missing something?

What others think about this?


> - small app to install/remove patches and of course, list them (patch_add,
> patch_delete, patch_info...)

I would be glad to add it. I'd like some enlightenment here too,
please. I remember that some people (like me) is unable to see why a
patch would be uninstalled. If the patch was incorrect, patch again.

I'd like to keep binpatch's approach as simple as possible. I like to
think of a binary patch as a simple tarball to unpack on / as opposed
to Solaris's patch dependencies and special programs to handle it.

But I am open and would love to read others' opinions and prove me
wrong if I am. Really.


> - when it is "perfect", force someone to import it in the official cvs ;-)

;-)

-- 
Gerardo Santana

[Openbsdbinpatch-misc] hello list

[Antoine J. <aja...@lp...>]

Hey.

Glad to see binpatch under the light again.

To follow the todo thread, interesting features could be:

- no need to install the sets, use mtree (drawback, make the patches 
bigger), so anyone with a stable system and /usr/src can create binpatches
- small app to install/remove patches and of course, list them (patch_add, 
patch_delete, patch_info...)
- when it is "perfect", force someone to import it in the official cvs ;-)

Cheers!

-- 
Antoine

Re: [Openbsdbinpatch-misc] GZSig Signing Patch

[Tobias W. <tob...@gm...>]

Hi everybody,

On Tuesday, 9. January 2007 02:23, Gerardo Santana G=F3mez Garrido wrote:
> Looks *great* to me.

Everything looks great so far. I don't really care about some people frowni=
ng=20
upon the idea of binary patches. In my opinion this is exactly what I need=
=20
for a lot of purposes:

* stable machines without the space to unpack the sources
* embedded installations
* any stable box that's way to slow to compile everything on it
* stable file sets for creating a LiveCD without src and gcc+libs

and so on. Creating a binary patch is way faster and less complicated than=
=20
making a release... Simple and easy rocks.

And the new features just make sense.

kind regards (& good night, it's already 03:00 again around here...)

Tobias

Re: [Openbsdbinpatch-misc] GZSig Signing Patch

[Mike E. <mi...@er...>]

Gerardo Santana G=F3mez Garrido wrote:
> 2007/1/7, Mike Erdely <mi...@er...>:
> Looks *great* to me.

Thanks.

> What about deleting this line:
>=20
> SIGNPASS?=3DNO
>=20
> Otherwise, SIGNPASS will be always defined.

Good call.  Works for me.

-ME

Re: [Openbsdbinpatch-misc] GZSig Signing Patch

[<ger...@gm...>]

2007/1/7, Mike Erdely <mi...@er...>:
> Attached is a patch to sign the patches using gzsig (suggested by Gerardo).
>
> You can define SIGNKEY and SIGNPASS in your Makefile.
> If you do not define a SIGNPASS variable, you will be prompted during package
> signing for the key's password.

Looks *great* to me.

What about deleting this line:

SIGNPASS?=NO

Otherwise, SIGNPASS will be always defined.

-- 
Gerardo

Re: [Openbsdbinpatch-misc] ARCH problem in macppc

[<ger...@gm...>]

2007/1/8, Tobias Weisserth <tob...@gm...>:
> Hi,
>
> On Tuesday, 9. January 2007 01:44, Gerardo Santana G=F3mez Garrido wrote:
> > z0mbix (to whom I'm CC'ing) found a problem in macppc. binpatch was
> > looking for the kernel directory "powerpc" instead of "macppc".
> >
> > He sent me the fix. He changed this line:
> >
> > ARCH=3D${MACHINE_ARCH}
> >
> > to this one:
> >
> > ARCH=3D${MACHINE}
> >
> > It has been tested on macppc (obviously) and i386. May someone else
> > test it on other platforms?
>
> Give me a couple of days until my exams are over, then I will test everyt=
ing
> on SPARC and I have an older RISC HP workstation which I haven't yet take=
n a
> closer look at though it should be able to run OpenBSD. I have to do an
> installation on the HP first and make an upgrade to 4.0 from 3.9 on the
> SPARC.

Fantastic. I'll wait for them.

And good luck in those exams.

--=20
Gerardo

Re: [Openbsdbinpatch-misc] ARCH problem in macppc

[Tobias W. <tob...@gm...>]

Hi,

On Tuesday, 9. January 2007 01:44, Gerardo Santana G=F3mez Garrido wrote:
> z0mbix (to whom I'm CC'ing) found a problem in macppc. binpatch was
> looking for the kernel directory "powerpc" instead of "macppc".
>
> He sent me the fix. He changed this line:
>
> ARCH=3D${MACHINE_ARCH}
>
> to this one:
>
> ARCH=3D${MACHINE}
>
> It has been tested on macppc (obviously) and i386. May someone else
> test it on other platforms?

Give me a couple of days until my exams are over, then I will test everytin=
g=20
on SPARC and I have an older RISC HP workstation which I haven't yet taken =
a=20
closer look at though it should be able to run OpenBSD. I have to do an=20
installation on the HP first and make an upgrade to 4.0 from 3.9 on the=20
SPARC.

kind regards,
Tobias W.

[Openbsdbinpatch-misc] ARCH problem in macppc

[<ger...@gm...>]

z0mbix (to whom I'm CC'ing) found a problem in macppc. binpatch was
looking for the kernel directory "powerpc" instead of "macppc".

He sent me the fix. He changed this line:

ARCH=${MACHINE_ARCH}

to this one:

ARCH=${MACHINE}

It has been tested on macppc (obviously) and i386. May someone else
test it on other platforms?

Thank you

-- 
Gerardo Santana

Re: [Openbsdbinpatch-misc] OpenBSD Binpatch To Do List

[Ingo S. <sch...@us...>]

Gerardo Santana Gómez Garrido wrote on Sun, Jan 07, 2007 at 03:30:03PM -0600:

> I appologize if anyone feels offended because I subscribed
> him to the list.

No, thanks, that's fine for me.
Even if i might seem a bit passive right now,
i like following the subject.

Yours,
  Ingo

Re: [Openbsdbinpatch-misc] Patch to use source from the CD

[<ger...@gm...>]

2007/1/7, Mike Erdely <mi...@er...>:
> Attached is a patch to use the source contained on the CD (there is no
> sys.tar.gz).  Just define CDSRC=<anything> in the Makefile.

Committed.

Except for

-       rm -rf ${WRKOBJ} ${WRKSRC}
+       @rm -rf ${WRKOBJ} ${WRKSRC}

I think it's good to let the user know what's happening behind the scenes.

Thanks!
-- 
Gerardo Santana

[Openbsdbinpatch-misc] GZSig Signing Patch

[Mike E. <mi...@er...>]

Attached is a patch to sign the patches using gzsig (suggested by Gerardo).

You can define SIGNKEY and SIGNPASS in your Makefile.
If you do not define a SIGNPASS variable, you will be prompted during package 
signing for the key's password.

-ME

[Openbsdbinpatch-misc] Patch to use source from the CD

[Mike E. <mi...@er...>]

Attached is a patch to use the source contained on the CD (there is no 
sys.tar.gz).  Just define CDSRC=<anything> in the Makefile.

-ME