Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 29 Jun 2014 11:41:01 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: massive Owl userland updates

Galaxy,

On Sun, Jun 29, 2014 at 11:27:29AM +0400, (GalaxyMaster) wrote:
> This is an update on my progress.  I've prepared the first batch of
> changes.  The full rebuild of Owl goes fine.  Currently I'm waiting on
> Solar's "green light" to start committing my changes.  We had a
> conversation with Solar and it's my understanding that Solar wants to
> fix the current state as, say, Owl 3.1, so my change will go to the
> current branch.  This requires some time from Solar, which he clearly
> currently lacks. :(

That's correct.  I feel that Owl-current is essentially stable right
now, and I'd prefer to preserve that as Owl 3.1, obsoleting 3.0-stable.
Your changes are so numerous that I expect Owl-current to be less stable
for a while after we've merged them.

> Switching to RPM 4.11.2

BTW, did you preserve our changes to RPM, such as package build time
comparison (in case Version and Release on a package being upgraded
remain unchanged between the old and the new revision)?

> revealed a handful of issues with our tree.
> Starting with minor things like wrong dates in our spec changelogs,
> missing unpackaged files (it seems that RPM 4.2's script for checking
> for unpackaged files has an issue and skips over files -- e.g. the
> postfix package installs the lmtp symlink into /usr/libexec/postfix, but
> that file was not detected by our previous RPM build scripts), files
> listed more than once in file lists, etc.  It also turned out that
> many of our packages contain fuzzy patches (patches which do not apply
> cleanly).  There were more than 30 of such packages and it took a while
> to locate and regenerate these patches.

Yeah, fuzzy patches are a problem.  I hope you reviewed each of those
cases individually, rather than merely regenerated the patches.  Each of
those cases is a risk of the chunk getting applied in a wrong place.

I usually check for any fuzz and review and then regenerate patches when
updating a package to a newer upstream version, but not everyone on our
team was as careful.

It's good if/that the new RPM will detect this problem.

> I've fixed all these issues, so my tree is building cleanly.  However, I
> did extensive tests on i686 only since a full rebuild of Owl on my
> server takes 1.5 hours and to fire x86_64 build system requires me to
> shutdown my 32-bit system and instantiate the 64-bit one -- which I'm
> doing just occasionally.

I'd be happy to setup a 64-bit OpenVZ container for your testing on a
mostly unused 8-core machine.

> I also spotted a lot of inconsistencies throughput the packages, so I'm
> working on a document that would describe the spec file conventions more
> cleanly and be more strict than the current documentation under
> native/Owl/doc (it's good, but I believe it should be reviewed and
> extended a bit).  I also plan to write a conformance checking script to
> test specs for following the conventions.

Sounds good.

> Below is a brief summary of the work I've done during the last month:
> ===
> sources@...lder-32:~/owl-dist $ ls -lh owl-update.diff
> -rw------- 1 sources sources 1.8M Jun 29 06:52 owl-update.diff
> sources@...lder-32:~/owl-dist $ diffstat owl-update.diff | tail -1
> 326 files changed, 16856 insertions(+), 28433 deletions(-)

Ouch.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ