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.