[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140629074101.GA19074@openwall.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
